Most software migrations fail gradually — a slow leak you catch in monitoring before it becomes an incident. A federation cutover doesn't get that courtesy. The moment the new identity provider becomes the one everyone authenticates against, every application that trusts it either works or it doesn't, for every employee, at the same time. There's no canary rollout for "can the whole company log in."
The failure mode that actually bites teams isn't the identity provider itself — vendors test that path obsessively, and the login screen almost always works in the demo. It's everything downstream of the assertion: a claim mapping that's subtly wrong for one department's group structure, a service provider that expects an attribute name the old IdP sent and the new one doesn't, a sync job that hasn't finished replicating group memberships by the time people start their day. None of that shows up in a successful test login by the person who configured it, because that person's own account is usually the best-provisioned one in the whole directory.
The fix isn't more testing of the happy path — it's running both systems in parallel long enough to prove the unhappy ones. Keep the old IdP live and authoritative while the new one runs alongside it, and don't call the cutover done until people outside the project team — ideally someone in a department nobody thought to test — have actually logged into the applications they use daily, not just the identity provider's own dashboard. That means picking a handful of real accounts across different teams, different device types, and different network conditions, and watching each one authenticate against every application in scope, not just the two or three that were convenient to test first. The projects that go badly are the ones that treat "the new IdP issued a token" as the finish line instead of the halfway point.
The other thing that gets skipped is the exit. Every federation cutover needs a break-glass path that doesn't depend on the system being cut over — an emergency admin account on the old IdP, or a local credential that bypasses federation entirely, tested before the migration and not invented during the incident. Teams that treat this as a checkbox instead of a rehearsed procedure are the ones paging everyone at 8am on a Monday because the rollback plan turned out to be a paragraph in a doc nobody had actually tried to execute.
None of this is really an identity-provider problem. It's an ownership problem — who has the authority to call go or no-go, who's actually watching login success rates in the first hour, and how fast the rollback trigger can be pulled once someone notices something's wrong. A cutover plan that lists the technical steps but not the person with their hand on the rollback lever isn't a plan, it's a hope. Get the ownership right and the technical migration is the easy part — most of the actual engineering work here was already validated in the parallel-run phase.
A federation cutover isn't finished when the new provider issues its first successful token. It's finished when someone who had nothing to do with the migration can log in on an ordinary bad-network Monday without calling anyone.