What should IAM teams do when some customers cannot switch IdPs immediately?

Keep the Existing Callback Stable While You Move Customers in Phases

The safest pattern is to preserve the old callback path as a compatibility layer while new IdP connections are staged behind it. That lets you migrate customers without forcing a synchronized cutover, and it reduces the chance that one tenant’s readiness blocks everyone else. The practical goal is continuity of sessions and predictable routing, not a perfect one-day switchover.

Where the migration touches the identity provider itself, treat the callback as a managed transition point rather than a permanent shortcut. A proxy model works when it can map old and new flows cleanly, preserve the right session context, and make routing decisions based on tenant state instead of ad hoc exceptions.

For customers that are still on the legacy path, the setup should be explicit enough that they can complete it without engineering help. A self-serve flow reduces migration friction, but it only works when the resulting configuration is deterministic, documented, and easy to verify.

Design the Fallback So It Does Not Become the New Normal

Staged migration is only safe if the old path has a clear retirement condition. If you leave both paths open indefinitely, teams tend to accumulate ambiguity about which system owns session handling, support, and incident response. That is where dual-running turns into long-term operational drag.

The cutoff should depend on proof, not optimism. Stable sessions, successful reroutes, and a clean customer-by-customer readiness signal should be visible before you decommission the previous path. If the old and new systems disagree on session state or callback behavior, resolve that before broadening the migration cohort.

Good migration design also limits blast radius. New customers can be routed directly to the new system, while existing customers move only after their configuration, test sign-in, and session persistence all pass the same acceptance criteria.

What Customers Need to See Before the Old Path Can Be Retired

Customers usually do not care about the internal migration architecture, they care about whether sign-in still works, whether sessions survive, and whether support can diagnose failures quickly. That means the migration experience needs clear state, such as migrated, pending, or legacy-only, so both the platform team and the customer know which path is authoritative.

When local IdP changes are still required, the setup flow should explain what must be changed, what success looks like, and how to confirm that the new connection is active. If the migration depends on callback behavior, give customers a way to test it before you switch them fully.

A clean decommission plan should also account for rollback. If a customer’s new connection fails in production, teams need a defined reversal path that restores the prior callback without creating a second layer of confusion.

Practitioner Guidance

What to prioritise: Keep one canonical callback behavior and make routing state-driven, not manual. The hardest failures in these migrations come from ambiguous ownership of the sign-in path, not from the customer-facing setup itself.

What to verify: Confirm that migrated customers can complete at least one full sign-in and session renewal cycle before you remove the legacy route. If that proof is missing, the migration is not ready for decommissioning.

Common mistake: Treating the proxy as a permanent workaround. The compatibility layer should buy time for orderly migration, not become an ungoverned second implementation of the same identity flow.

Practitioner takeaway: The right move is phased continuity with an explicit retirement gate, because migration safety depends on proving stable behavior before legacy access is withdrawn.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of orphaned service accounts and stale tokens?
• What breaks when teams reuse workforce IAM patterns for customers?
• How should security teams reduce identity risk when IAM tools cannot show the full attack surface?
• How should IAM teams handle accounts that cannot be mapped to a human owner?