Most teams go into an IdP migration thinking they’re moving login.
Recreate SAML apps, sync users, test MFA, cut over. If users can sign in, the migration worked.
That’s the expectation.
What actually happens is you end up touching every place identity shows up in the business. Not just authentication, but provisioning, roles, automation, integrations, and all the ways access has quietly evolved over time.
So the better question isn’t “what breaks?”
It’s:
Where is identity embedded in ways we don’t fully see yet?
Because those are the parts that break.
For core apps, SSO tends to hold up. You rebuild integrations, update metadata, and users can log in.
The problems show up in the long tail. Older apps, custom configurations, edge-case policies, and anything that relied on “just make it work” decisions over time. Some apps fall back to local auth, some behave differently under MFA, and some only fail under specific conditions.
The migration doesn’t break SSO as much as it reveals that your SSO coverage was never as uniform as you thought.
Provisioning is where teams expect automation and find approximation.
Over time, most environments accumulate a mix of SCIM, manual fixes, and one-off exceptions. Group mappings evolve, roles get assigned directly in apps, and “temporary” workarounds become permanent.
When you rebuild this in a new IdP, the integrations may connect, but the behavior doesn’t line up. Users get created without the right roles, deprovisioning doesn’t trigger consistently, and duplicate accounts appear.
Nothing looks broken at a system level. It just doesn’t behave the way the business expects.
Groups are supposed to represent intent, but that intent is rarely documented.
You inherit nested groups, dynamic rules, naming conventions that drifted, and groups used for both access and policy. When you try to recreate this in a new IdP, the models don’t map cleanly.
What starts as configuration becomes reverse engineering. Teams spend time figuring out what a group was meant to do before they can rebuild it. That’s where migrations slow down, because you’re not copying structure, you’re reconstructing meaning.
You start with an app list from your IdP and assume it reflects reality.
Then you test real workflows and discover tools that were never connected. Apps using local accounts, tools adopted directly by teams, systems accessed through OAuth or API keys. They don’t break during migration because they were never part of it.
They show up when something stops working or when a user asks where their access went.
This is where migrations turn into discovery. You learn what your environment actually looks like by seeing what’s missing.
A lot of access today doesn’t go through login. It goes through integrations.
Users and systems connect apps to platforms like Google Workspace or Microsoft Entra ID, granting permissions that allow data to move and workflows to run.
These connections depend on tokens, scopes, and identity assumptions that don’t always survive a migration.
When they fail, they don’t fail loudly. A sync stops updating, a workflow doesn’t trigger, an agent can’t complete a task. The issue surfaces later, disconnected from the migration event.
Service accounts rarely get first-class treatment in migration plans.
They live in cloud platforms, SaaS apps, CI/CD pipelines, scripts, and integrations. They rely on API keys, roles, and permissions tied to the old identity model.
When that model changes, jobs fail, pipelines break, and integrations lose access.
The problem is timing. These systems run in the background, so failures show up when something downstream depends on them, not when the migration happens.
After migration, users can log in. Apps are connected. Nothing appears broken.
But access is off.
People have permissions they shouldn’t have. Others are missing access they relied on. Role changes didn’t translate. Temporary fixes became permanent.
This happens because migrations validate authentication, not effective access.
You prove users can get in. You don’t always prove that what they can do once inside is still correct.
The breakage isn’t random.
Authentication tends to survive. Everything layered on top of it is where things drift.
The migration didn’t create these problems. It surfaced them.
An IdP migration feels like a system change.
In reality, it’s a moment where you’re forced to answer a harder question:
Where does access actually live in our environment?
Not just in the IdP, but across apps, integrations, automation, and non-human identities.
That’s a much bigger surface area than login.
If you’re planning an IdP migration, assume SSO will be the easiest part and everything around it will take longer than expected.
Inventory more than just applications. Look for integrations, OAuth connections, service accounts, and automation. Treat provisioning and group logic as redesign work, not copy-paste work. Plan time after cutover to observe what actually breaks, not just what you can test ahead of time.
And don’t treat successful login as success.
Because what breaks during a migration isn’t authentication.
It’s everything that depended on it.
