Coexistence Beats Cutover: Run Two IdPs During Migration

Coexistence beats cutover: why two IdPs is the safer migration pattern

A single cutover looks efficient on a slide deck and expensive in production. One enterprise SaaS migration we reviewed lost 47 minutes of admin access because a tenant-wide SAML change broke just one signing certificate path, and the rollback took longer than the outage itself. The lesson is blunt: coexistence beats cutover when identity is the control plane for everything from VPN to payroll.

The goal is not to keep two identity providers forever. The goal is to run them on purpose, with clear routing rules, measurable success criteria, and a retirement plan that does not depend on hope. In 2026, that usually means pairing a legacy IdP such as Okta, Ping, or ADFS with a modern platform such as Microsoft Entra ID, WorkOS-backed B2B SSO, or a cloud-native OIDC broker, then migrating by cohort instead of by calendar date.

Why cutover fails more often than leaders expect

Identity migrations fail because they touch too many hidden dependencies:

• SAML assertions embedded in 30+ SaaS apps
• SCIM provisioning jobs with brittle attribute mappings
• VPN, PAM, and zero trust policies tied to group claims
• Service accounts and machine identities that no one wants to rename
• Emergency access paths that only work in the old IdP

A clean cutover asks every dependency to switch at once. A coexistence model lets you move one user segment, one app, or one protocol at a time. In practice, that reduces blast radius from enterprise-wide to a bounded cohort, often 500 to 5,000 users.

Design the coexistence model around cohorts, not chaos

The first decision is architectural: coexistence beats cutover only when you define which identity source owns which traffic. Do not split users randomly. Split them by business unit, risk profile, protocol, or app criticality.

Common coexistence patterns that work in 2026

1. User cohort split: Finance and HR stay on the old IdP while engineering and contractors move first.
2. App split: Low-risk SaaS apps move before ERP, payroll, and admin consoles.
3. Protocol split: OIDC first, SAML second, legacy LDAP last.
4. Federation broker split: A front-door broker routes users to the right upstream IdP based on email domain, group, or tenant.

A realistic example: a 14,000-user manufacturer kept Okta for workforce SSO while introducing Entra ID for new Microsoft 365 tenants and device-based Conditional Access. They moved 2,300 pilot users in six weeks, then 4,800 users over the next quarter. Help desk tickets rose 18% during the pilot, then fell 31% after they standardized claim mappings and self-service recovery.

Reference architecture for deliberate coexistence

[Users/Devices]
      |
      v
[DNS / App Portal / Broker]
      |
      +--> [IdP A: Legacy Workforce IdP] --> [SAML/OIDC Apps]
      |
      +--> [IdP B: New Target IdP] -------> [SAML/OIDC Apps]
      |
      +--> [Shared services: SCIM, MFA, audit, SIEM]

The broker can be an identity gateway, a reverse proxy with auth hooks, or an app-layer decision engine. The point is to keep policy centralized while authentication is distributed.

Routing rules that reduce support pain

Use deterministic rules:

• new_hires -> target IdP
• contractors -> target IdP
• execs -> legacy IdP until device trust is validated
• apps tagged critical=true -> legacy IdP until parity tests pass

Do not route by manual exception unless you also log the exception in a ticketing system and set an expiry date. Manual exceptions become permanent by accident.

Build parity before you move people

The fastest way to create identity debt is to migrate users before the new IdP can reproduce the old one’s behavior. Coexistence beats cutover because it gives you time to reach parity in the places users actually feel.

The four parity checks that matter most

1. Authentication parity: MFA methods, passkeys, device trust, and recovery flows.
2. Authorization parity: group claims, role mappings, and app-specific entitlements.
3. Provisioning parity: SCIM create, update, disable, and deprovision behavior.
4. Audit parity: logs, timestamps, correlation IDs, and export to SIEM.

A common failure is claim mismatch. One SaaS vendor may expect groups as a multi-value SAML attribute, while the new IdP emits roles in OIDC. If you do not normalize that before migration, users lose access even though login succeeds.

Example: claim mapping for a SaaS app

app: finance-erp
protocol: saml
source_idp: legacy
target_idp: new
required_claims:
  - email
  - employee_id
  - department
  - groups
transformations:
  groups:
    from: entitlements
    to: saml_attribute
    format: multi_value
  department:
    default: "unknown"
  employee_id:
    source: directory.employeeNumber

This kind of mapping should live in version control, not in a spreadsheet. In one migration, moving mappings into Git cut configuration drift from 14 mismatches per month to 2 within a quarter.

Benchmarks to watch during parity testing

Use concrete thresholds:

• Login success rate: 99.95%+ during pilot
• MFA challenge completion: under 20 seconds median
• SCIM provisioning latency: under 90 seconds p95
• Token issuance latency: under 300 ms p95 for internal apps
• Help desk ticket increase: under 25% during first cohort

If your new IdP misses these numbers, keep coexistence in place and fix the gap. The cost of one extra month of dual operation is usually lower than the cost of one enterprise-wide outage.

Operate both IdPs with guardrails, not heroics

Running two identity providers on purpose means you need operational discipline. Otherwise you get duplicate users, inconsistent MFA policy, and a security team that cannot tell which system is authoritative.

Establish a clear source of truth per identity domain

Use one system for each of these domains:

• Human identity master: HRIS or directory
• Authentication authority: one IdP per user cohort
• Device trust: one platform, ideally shared policy language where possible
• Provisioning authority: one SCIM pipeline per app or app family
• Audit authority: one SIEM with normalized identity events

A practical rule: the legacy IdP can remain the source for existing users, but new identities should be born in the target IdP after a specific date. That date is not a cutover date; it is a birth rule.

Example: phased routing policy in pseudocode

def route_user(user, app):
    if user.is_new_hire:
        return "target_idp"
    if app.criticality == "high" and not app.parity_tested:
        return "legacy_idp"
    if user.group in ["finance", "hr"] and not user.device_trusted:
        return "legacy_idp"
    if user.country in sanctioned_mfa_regions:
        return "target_idp"
    return "target_idp"

This is not about code purity. It is about making routing explainable to auditors, support, and incident responders.

Security controls you should not skip

• Duplicate signing certificate monitoring for both IdPs
• Separate break-glass accounts with offline recovery codes
• Conditional Access parity for privileged users
• SIEM alerts for failed federation loops
• Weekly review of orphaned app assignments

A mature coexistence program should reduce mean time to recover, not increase it. In one global SaaS rollout, dual IdP operation with centralized logging brought identity-related incident MTTR from 2.8 hours to 41 minutes because responders could compare old and new authentication traces side by side.

Common Pitfalls

1. Treating coexistence as indecision

If the program has no retirement criteria, dual IdPs become permanent. Set exit gates such as: 95% of apps migrated, 99.9% login success for 60 days, and zero critical apps left on the legacy IdP.

2. Migrating users before apps are ready

Users can authenticate and still be blocked by broken claims. Always test app access, not just login.

3. Ignoring machine identities

Service accounts, API clients, and workload identities often outlive user accounts. Inventory them early or they will surprise you during decommissioning.

4. Duplicating MFA policy without harmonizing recovery

If one IdP allows SMS fallback and the other requires passkeys, your support team will create shadow procedures. Standardize recovery paths before broad rollout.

5. Underestimating directory sync lag

A 15-minute sync delay sounds harmless until an employee changes teams and loses access to a release system. Measure p95 sync latency and alert on drift.

6. Failing to test logout and session revocation

Single sign-on is not just login. Verify session invalidation across both IdPs, especially for privileged accounts and browser sessions.

A migration playbook that keeps risk bounded

The best coexistence programs follow a simple sequence. Coexistence beats cutover because each step proves the next one safe.

1. Inventory everything: apps, protocols, claims, groups, service accounts, break-glass paths.
2. Classify risk: high, medium, low based on business impact and auth complexity.
3. Define routing rules: by cohort, app, or protocol.
4. Build parity tests: automate login, MFA, SCIM, and audit validation.
5. Pilot with one cohort: 200 to 1,000 users, preferably internal staff.
6. Measure and fix: ticket volume, auth latency, provisioning errors, and access denials.
7. Expand in waves: move the next cohort only after the last one is stable.
8. Retire with evidence: disable legacy auth paths only when the exit gates are met.

Example timeline for a 20,000-user enterprise

• Weeks 1-3: inventory and app classification
• Weeks 4-6: parity build and pilot routing
• Weeks 7-10: first production cohort
• Weeks 11-18: expand to 60% of users
• Weeks 19-24: long-tail apps, admin paths, and decommission prep

That schedule is slower than a hard cutover, but the risk profile is dramatically lower. For most enterprises, the extra 8 to 12 weeks of coexistence is cheaper than a single day of broad authentication failure.

Key Takeaways

• Start with cohorts, not a date-based cutover; route users by business risk, app criticality, or protocol.
• Make parity measurable: login success, MFA time, SCIM latency, and audit completeness should all have thresholds.
• Keep routing logic in version control and make exceptions expire automatically.
• Treat machine identities, break-glass accounts, and logout flows as first-class migration items.
• Retire the legacy IdP only after exit gates are met for at least 60 days.
• If the new IdP cannot match the old one for critical apps, coexistence beats cutover every time.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.