Replace Legacy SSO with a Modern IdP

The scenario

Your organisation has 5–15 years of accumulated authentication infrastructure: an on-prem ADFS deployment, perhaps a homegrown SSO portal, plus the inevitable handful of apps with their own user databases that nobody wants to touch.

You've decided to consolidate on a cloud-native IdP. The question is how, not whether.

The phased approach

Phase 0: Inventory & risk-rank

• Catalogue every authentication path. Every app, every account, every privileged credential.
• Risk-rank each by: business criticality, current auth quality, vendor support for modern protocols.
• Output: a heat-map. Plan the migration sequence based on this, not on org-chart politics.

Phase 1: Greenfield foundation

• Stand up the new IdP (Okta or Azure AD) alongside existing infrastructure. No migration yet.
• HRIS-driven provisioning into the new IdP.
• AD-sync if applicable.
• Test with a pilot group (50–100 users) on 2–3 low-risk apps.

Phase 2: Tier-1 migration

• Top 10–15 apps with strong vendor support for SAML/SCIM. M365, Slack, AWS, GitHub, Salesforce.
• Each app: parallel-run period (both old and new IdP working), then cut-over.
• Communications matter: end users should not notice the cut-over. If they do, you've already failed.

Phase 3: Conditional access

• With identity flowing through the new IdP for tier-1 apps, layer on policies.
• Device-trust integration, geo, risk-score, MFA requirements.
• Test thoroughly before enforcing — false positives here mean people can't log in to do their jobs.

Phase 4: Long-tail

• Remaining apps. Categorise by protocol support: SAML, OIDC, header-based (via edge gateway), or out-of-scope.
• Out-of-scope apps either get migrated, replaced, or accept their reduced security posture (with explicit risk acceptance).

Phase 5: Decommission

• Old IdP gets shut down in stages. Keep it in read-only mode for 30–90 days for audit/troubleshooting.
• Document the final state. Hand over to ops with a runbook for common scenarios.

Common pitfalls

Underestimating the long tail. The 80/20 rule is real: 20% of apps will consume 80% of project time. Budget accordingly.

Skipping the pilot. Going straight to a big-bang migration of multiple apps because "it'll be faster" is the most expensive shortcut in IAM.

Ignoring service accounts. Human users are the obvious migration target. Service accounts and machine identities are equally important and often forgotten until something breaks.

Insufficient communications. End users tolerate change if they understand it. Surprise auth changes generate support tickets that overwhelm helpdesk and erode goodwill.

How long will it take?

For a 1,000–5,000 employee organisation with 50–150 apps and reasonably modern infrastructure: 6–9 months end-to-end.

Add 3–6 months if you're integrating with on-prem AD, have a heavy-regulation environment, or need to handle privileged access in the same project.

When this use case doesn't apply

If your existing IdP is working, fully integrated, and meeting your audit needs — don't migrate. The risk of a mid-flight migration outweighs the marginal gains in most cases. The time to migrate is when an audit finding, a vendor end-of-life, or a strategic platform shift forces the conversation.