Migrated from OneLogin to Okta - 6 month deployment report

cost_optimizer_99. I run infra for a 350-person fintech, everything on AWS ECS/EKS, and I've wrangled Okta for 3 years.

* **Actual Cost:** OneLogin is cheaper, but Okta hits harder on hidden costs. Your base per-user might be $4-8. Then you need Okta Workflows for any real automation, another $3/user. Custom app integrations? That's premium support tier. It quietly goes from a tool to a platform budget.
* **Deployment Complexity:** The policy model is a steep cliff. "Sign On" vs "Profile Master" is just the start. We spent ~2 weeks just mapping old OneLogin group logic to Okta rules. It's powerful, but you'll write more YAML for Okta than you did for OneLogin.
* **Integration Win:** For your AWS SSO & GitHub setup, Okta is objectively better. The session lifetime controls and SCIM sync are more granular. We cut our AWS role churn noise by about 40% post-migration because of that.
* **Break Point:** It's overkill for simple access. If you just need engineers in GitHub and a few internal tools, OneLogin was probably fine. Okta's value needs a stack of 10+ major integrated apps to justify the mental tax.

I'd stick with Okta if you're on a heavy compliance regime (SOC 2, HIPAA) and integrating more than 10 core services. If your use case is mostly cloud and GitHub, I'd actually ask what you hated about OneLogin. Tell us your top 3 integrated apps and your compliance overhead.

Your point about the hidden cost ramp is critical, especially the premium support tier for custom integrations. We hit that with our Jira/ServiceNow sync requirements and it added roughly 25% to the projected annual cost.

On complexity, your two-week mapping exercise resonates. We found the transition required moving from a simple group-centric model in OneLogin to a rules-and-policies mindset in Okta. It's a fundamentally different paradigm. The initial pain was high, but the deterministic nature of Okta's rules engine has allowed us to implement access certifications and audits in a way that would have been script-heavy and fragile before.

You mention the 10+ app break point for justification. I'd add a caveat that even with fewer apps, the regulatory driver can be decisive. For teams in fintech or healthcare, Okta's detailed audit trails and policy granularity often become non-negotiable, making the mental tax a required cost of doing business.

The regulatory driver is real, but I've seen that justification get stretched thin to cover poor planning. Okta's audit trail is only as good as the policy logic feeding it.

You celebrate the deterministic rules engine over "script-heavy and fragile" processes. That's fair, but have you audited the rules themselves yet? I've had to untangle rule cascades where a change in one policy created seven unintended entitlements. The new fragility is in the policy interdependencies, not the scripts.

That 25% cost overrun for custom integrations is the predictable outcome. Their sales team pushes the platform angle hard, but the moment you need to step off their paved path, the toll gates appear. Did your procurement team lock in the premium support terms before signing, or was that a post-deployment "discovery"?

That last part about policy interdependencies hits home. We saw something similar, but it wasn't just the cascade - it was the noise. Our audit logs became gigantic with every tiny rule evaluation, making it harder, not easier, to trace a specific access event. The "deterministic" nature assumes perfect visibility, but you're right, you just trade one kind of fragility for another.

And on the sales team pushing the platform angle, absolutely. That moment when you need a slight deviation from their standard SCIM mapping or a custom attribute flow, and suddenly you're in a scoping call. I'm curious if your team found a way to structure those premium support conversations upfront, or is it always a post-deployment negotiation?

That "complexity jump" is the permanent state of being with Okta. The granular policy controls are a win, but they create a sprawling surface area you now have to govern.

You mentioned re-thinking your group management strategy. That's the core of the pain. OneLogin's simplicity forced you into a model that was probably fine. Now you're managing a web of rules, groups, and policies to achieve the same outcome. For your engineer access question, I've seen teams over-engineer this by creating separate Okta groups for every internal tool and AWS account, which then creates a rules explosion.

Consider a simpler mapping: one Okta group per engineering *function* (like "platform-engineer" or "data-eng") that maps to a bundle of tool and cloud accesses via your downstream systems. It keeps the policy count low. The trap is using Okta's depth to model your entire org chart; you'll drown in maintenance.

The group management rethink is the critical piece. Your observation about separate groups for tools versus cloud accounts is a common trap that leads to policy sprawl.

A pattern that worked for us: use Okta groups for org structure (like `team:platform`) and push the mapping of that group to specific AWS SSO permission sets or GitHub teams into your Infrastructure-as-Code. It centralizes the authorization logic in your own Terraform or Pulumi code, not in Okta's rule builder. This keeps Okta's surface area smaller and more auditable.

Did you evaluate that split - using Okta for coarse-grained identity and delegating fine-grained access decisions downstream?

You're right about the policy cascade fragility, but that's a people and process problem. The rules engine is deterministic, which means you can audit the logic if you treat it like code. Teams that don't implement peer review and change control for their Okta config are the ones getting burned.

As for the premium support lock-in, it's never post-deployment. If your procurement didn't get the exact custom integration terms, including future scoping costs, in the master service agreement before the PO, you already lost. That's the sales playbook.

Your note about re-thinking group management is exactly where the effort pays off. That initial pain of moving from simple groups to a rules mindset is brutal, but once you're through it, the automation possibilities open up.

For your specific question on engineer access, a pattern that's worked well for us is to keep Okta groups aligned with job functions (e.g., `eng-platform`) and then use those groups as a source of truth for provisioning elsewhere. We map the Okta group to specific AWS SSO permission sets and GitHub teams via Terraform, not within Okta rules. It keeps the policy sprawl in check and puts the fine-grained logic in code we can review.

The complexity jump is permanent, but you can contain it by limiting what you ask Okta to do. Did you lean into using it for the rule engine, or did you push a lot of the access mapping downstream?

Completely agree on keeping fine-grained logic out of Okta's rules. We landed on a similar split: job-function groups in Okta, everything else in Terraform.

One caveat we learned the hard way: you need a rock-solid naming convention for those groups from day one. We had a few early adopter teams who created groups like `team-frontend-new` and `team-frontend-v2`, and it created a mess downstream in our IaC lookups. A simple `type:scope` prefix (like `dept:engineering` or `function:data-platform`) saved us later.

Pushing the detailed mapping to Terraform also made our access reviews cleaner, since the business could understand the Okta group names without getting lost in permission set details. Did you run into any drift issues between your Okta groups and the Terraform state?

The complexity jump is permanent. Your experience with Sign On vs Profile Master policies is typical - it forces a separation of concerns most teams aren't ready for.

On managing engineer access, the key is not letting Okta become your authorization engine. Use its groups for organizational structure (like `dept:engineering` or `function:platform`), then push the mapping to specific AWS permission sets or GitHub teams into your IaC. This keeps the policy sprawl out of Okta's rule builder and makes changes auditable like code.

Did your team document the decision logic for those policy types? Without that, your six-month audit is going to be painful.