Identity orchestration and IdP migration
Most identity pain at scale is not the login box, it is the wiring behind it: multiple identity providers, a legacy system you cannot rip out, and applications hard-coded to whatever they were built against. Identity orchestration is the layer that decouples those apps from the identity providers underneath, so you can change one without rewriting the other.
What orchestration does
An orchestration layer sits between your applications and your identity providers and routes the journey: which IdP handles a given user, when to step up, how to add modern authentication, and how to enforce consistent policy across all of them. The practical payoff is migration: moving off a legacy IdP, or running old and new in parallel, without refactoring every application.
A related idea is the identity data fabric, which unifies identity data across directories and systems into one authoritative view that downstream IAM and access decisions can trust.
Platform-native vs standalone
Some CIAM platforms include orchestration (Ping’s DaVinci, Descope’s flows). Standalone vendors specialize in the vendor-neutral, multi-IdP case, which is where heterogeneous estates and migrations live; see the orchestration lane of the market map.
What to ask a CIAM vendor
- Can we migrate from a legacy IdP without changing application code?
- Can journeys be modeled visually, with conditional routing, across multiple IdPs?
- Does the layer enforce consistent policy and modern auth over incompatible systems?
- Is identity data unified into one authoritative source, or queried per system?
- Does orchestration come native, or do we add a standalone layer?
The buyer takeaway: orchestration earns its place when you have more than one IdP or a migration ahead; for a single greenfield stack it is usually overkill. See enterprise and B2B identity, then run the vendor matcher.