OIG is fine until it isn't. The point where it stops being fine is usually one of three places: an app that doesn't support SCIM and never will, a certification campaign that hits the 250-app ceiling, or a contractor lifecycle that you ended up building in Workflows because OIG doesn't model contractors as a first-class identity. Once you're past one of those, the other limits show up too.
This guide is for teams that have decided to move. What changes the day Iden goes live. How the concepts map. The playbook. The gotchas specific to leaving OIG. The timeline. The rollback plan.
What changes day one
Three things shift the moment Iden is live.
You stop maintaining Workflows for app coverage. The Workflows builder is good at one-off business logic. It's a maintenance trap when you've used it to fill in the apps OIG can't natively govern. Iden replaces the connector half of that work. The flows you actually want (custom approvals, notification routing, business rules) keep living in Workflows. The apps just get governed natively.
You stop forcing enterprise plan upgrades for SCIM. OIG requires apps to expose SCIM at the right plan tier to govern them. Iden provisions whatever's on standard plans through API or admin-panel access. No SCIM tax, no upgrade conversation with finance.
You stop reviewing access at group level. OIG certifications run against Okta Groups. The reviewer sees "is this person still in the Engineers group?" not "should they have admin on the staging database?" Iden runs reviews per entitlement, with usage context, across the actual stack.
Okta SSO stays. The IdP stays. The HRIS stays. The Workflows you built for actual business logic stay. The work is replacing OIG's governance layer, not your authentication stack.
Concept mapping
The terms mostly map cleanly. A few get renamed, a few collapse together, a few are new because OIG doesn't have an equivalent.
| Okta IGA | Iden | |---|---| | Access Certifications | Access Reviews | | Lifecycle Workflows (for app provisioning) | Connectors (native, no flow-building) | | Lifecycle Workflows (for business logic) | Stays in Okta. Iden doesn't replace this. | | Okta Groups | Iden Roles + per-app entitlements | | Access Request (Okta Identity Engine) | Iden Access Request | | Identity Threat Protection / ISPM | Native non-human identity governance | | CSV reports | Audit log + GRC integrations (Drata, Vanta, Secureframe) |
The biggest mental shift: Okta thinks in groups. Iden thinks in entitlements. Groups still exist (we ingest them from Okta), but they're a coarse layer over the fine-grained per-app access Iden actually governs.
The playbook
Five phases. The full migration typically lands in two to four weeks of clock time, less than that in active engineering effort.
1. Export from OIG
Pull four things from the OIG side:
- Current group memberships (CSV from Okta admin)
- Certification campaign history (for compliance handoff continuity)
- Active access requests and their approval routes
- Workflows source (the JSON definitions; you'll inspect, not import)
The Workflows source isn't imported into Iden. We use it to understand what your team was doing with Workflows, so we can confirm which parts move to Iden's connector layer and which parts stay in Okta as actual business logic.
2. Connect HRIS and apps
Iden connects to your HRIS (Workday, BambooHR, Personio, Rippling, HiBob, or whatever you run) as the source of truth for joiner-mover-leaver. Then the apps. First 15 in under an hour. The rest over the next few days.
The apps OIG couldn't reach get connected the same way as the ones it could. Same governance layer applies to both. This is the part where the 80% gap closes in practice.
3. Parallel run
OIG keeps doing its job while Iden takes over connector-by-connector. The parallel window is usually two to four weeks. Both systems run; you check that Iden's actions match what OIG would have done, or, more often, that Iden does the actions OIG was leaving as Jira tickets.
The parallel run gives you the audit-trail handoff. The last OIG certification cycle and the first Iden access review run on overlapping windows, so the compliance evidence is continuous.
4. Cut over
When the team is comfortable, you flip the trigger. The HRIS now drives Iden. OIG stops being the source of truth for governance actions. Okta SSO continues handling authentication. The Workflows you kept continue running.
There's no big-bang moment. You can cut per app, per department, per process. Most teams do it all at once because the parallel run already proved it works.
5. Decommission
Okta IGA gets unbundled from the Okta contract at renewal. Workflows stays. The OIG admin role is unassigned. The certifications module is paused, not deleted, in case you want the historical evidence accessible. Most teams keep OIG admin access in read-only for two cycles post-cut, then turn it off.
Common gotchas specific to OIG
A few patterns we've seen across teams making this move.
The Workflows trap. Teams that used Workflows extensively for app provisioning are sometimes surprised by how much of that machinery they can retire. The instinct is to map every Workflow to an Iden flow. The right move is usually to delete most of them. The work happens in connectors now, not flows.
The certification campaign overlap. Don't time your move to land in the middle of a quarterly certification. Either complete the OIG campaign first and start fresh with Iden, or start the Iden cycle two weeks before the OIG one was scheduled and roll evidence forward.
The contractor situation. If you built contractor lifecycle in Workflows because OIG doesn't model contractors natively, this is the easiest single win in the migration. Iden has first-class contractor identity. The Workflows can be retired entirely on this dimension.
The 250-app certification ceiling. If you've worked around OIG's 250-app limit by splitting campaigns artificially, you can collapse those back into single campaigns in Iden. There's no ceiling.
The "Okta Groups are the source of truth" assumption. Teams sometimes carry the assumption forward that Okta Groups should drive entitlements in Iden. They can (Iden ingests Okta Groups), but most teams find per-app entitlements are a better fit. You don't have to decide on day one. Start with groups. Refine over the first quarter.
Timeline by stack size
Sizes are rough and depend more on app diversity than on user count.
Small (under 200 employees, fewer than 30 connected apps): 5 to 10 business days, total. Most of that is parallel-run watch time, not active work.
Mid (200 to 800 employees, 30 to 80 apps): 2 to 4 weeks. Parallel run is the longest window. Setup and cutover are days, not weeks.
Larger (800 to 2,000 employees, 80+ apps, multiple HRIS instances, complex Workflows usage): 4 to 8 weeks. Parallel run extends. Some Workflows decisions need engineering review. The team that built your OIG implementation should be involved.
If you have stack constraints that suggest a longer timeline (regulated industry, on-prem-heavy, more than one IdP), tell us at office hours. We'll walk through what's realistic for your specific situation.
Rollback plan
If something goes wrong during parallel run, OIG is still running. You haven't decommissioned anything. The rollback is "switch the HRIS trigger destination back to OIG." Iden's audit trail is exportable and preserved, so you don't lose evidence of the parallel-run period.
If something goes wrong after cutover, the rollback reverses: re-enable OIG's HRIS connection, switch the trigger back. Iden's audit log of every action up to that point is preserved. We've never seen a customer actually use this beyond the first parallel cycle, but the path exists.
Where to ask for help
Migration office hours run weekly. The same team that builds Iden runs them. Bring your OIG configuration, your timeline, and any specific Workflows you're unsure about. We'll walk through what the migration looks like for your situation and where the work concentrates.