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 on day one. How the concepts map. The playbook. The gotchas specific to leaving OIG. The timeline. The rollback plan.
What changes day one
Three things shift on day one.
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. The connector half of that work moves. 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. Whatever sits on a standard plan gets provisioned through its API, or through admin-console automation where there is no usable API. 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?" Reviews run 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 sit as a coarse layer over the fine-grained per-app access underneath.
The playbook
Five phases. The full migration typically lands in two to four weeks of clock time, less than that in active engineering effort.
1Export 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. We use it to understand what your team was doing with Workflows, so we can confirm which parts move to the connector layer and which stay in Okta as actual business logic.
2Connect HRIS and apps
Connect the 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 coverage gap closes in practice, and our SCIM Tax Index is where the per-vendor detail lives if you want to see which of your apps sit on the wrong side of it.
3Parallel run
OIG keeps doing its job while coverage transfers connector by connector. The parallel window is usually two to four weeks. Both systems run; you check the actions match what OIG would have done, or, more often, that the actions OIG was leaving as Jira tickets now happen.
The parallel run gives you the audit-trail handoff. The last OIG certification cycle and the first access review here run on overlapping windows, so the compliance evidence is continuous.
4Cut over
When the team is comfortable, you flip the trigger. The HRIS now drives governance directly, and OIG stops being the source of truth for it. 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.
5Decommission
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 one-to-one. 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, or start the new 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. Contractor identity is first-class here. 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. There's no ceiling.
The "Okta Groups are the source of truth" assumption. Teams sometimes carry the assumption forward that Okta Groups should keep driving entitlements. They can, since the groups are ingested, 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." The 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. The 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 the product 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.