Ask three firms to quote an IdP migration and you will get three numbers with one thing in common. All three are priced as if every application is a custom project.
That pricing is honest under the traditional method. A migration team opens each application, reverse-engineers what the old tenant does, and rebuilds it by hand in the new one. Nobody knows what is inside application 73 until an engineer opens it. So the quote carries a buffer for every unknown, and the unknowns are the whole tenant.
We think the premise is wrong. IdP configuration is structured data. The moment you treat it that way, the cost curve of a migration stops looking like construction and starts looking like computation.
What a migration actually costs
Strip a migration quote down and three costs remain.
Discovery is the first. Someone has to learn what the current tenant does: which policies exist, which groups feed which applications, where the exceptions hide. In most programs this is weeks of interviews and screenshots. The knowledge lives in a console, not in a document.
Per-application work is the second. Each integration gets rebuilt by hand: settings, mappings, assignment rules, the test loop. The hundredth application costs roughly what the first one did. There is no learning curve because there is no shared representation of the work.
Risk is the third, and it is the quiet one. When a cutover breaks, the team debugs in production against configuration nobody fully recorded. Rollback means remembering what the old state was. The buffer for that fear is priced into every quote.
All three costs share a root cause. The configuration is not portable. It lives inside the IdP's own data model, shaped by years of console clicks, readable only by clicking through it again.
The mechanism: read, normalize, write
We make configuration portable by treating the IdP control plane as data. Our control-plane orchestration runs three operations against any tenant.
READ. An IdP MCP server exposes users, groups, policies, and application integrations as addressable tool calls. A normalized read captures the full state of the tenant into a canonical model. Run it twice and you get the same result. Every read is version-controlled.
NORMALIZE. Fragmented entitlements collapse into a single policy model. Conflicts surface. Drift between intent and configuration becomes visible. Edge cases queue for a human decision instead of hiding until cutover night.
WRITE. The normalized policy writes back to the destination tenant through its MCP server. Every write logs the agent identity, the human approver, and the diff. Rollback is a write of the previous version, not an act of memory.
None of this is a methodology slide. It is shipped tooling that has run against production Okta tenants. The point of this essay is what it does to the economics.
What happened at Temporal
Temporal needed to consolidate 40 applications onto one IdP. Under the traditional method, that is a quarter of per-application work, priced accordingly.
We read the source configuration, normalized it into one policy model, and wrote it to the target. Humans made the policy calls and reviewed the exceptions. The agents, working through the Authonomy accelerator, did the per-application mechanical work.
The consolidation completed in one day.
The number matters less than its shape. The cost of the migration concentrated in the normalize step, where the judgment lives. The per-application step, which used to dominate the budget, became close to flat. Application 40 cost about what application 4 did.
The new economics
Three things change when configuration is data.
Discovery stops being an interview process. The READ operation produces a complete, current picture of the tenant in hours. You price the work from evidence, not from a guess plus a buffer. The surprises surface before the contract is signed, which is where both sides want them.
Marginal cost per application collapses. When configuration moves through a normalized model, the work scales with the number of policy decisions, not the number of applications. Decisions are the part that deserves senior attention anyway.
Risk gets cheaper because rollback is real. A versioned, auditable write trail means a failed cutover is a revert, not an investigation. You can take migrations in small, reversible steps instead of one weekend of held breath.
There is a buyer-side consequence too. Migration quotes built on per-application labor deserve scrutiny now. The right question for any migration partner is no longer how many engineers they will assign. It is whether they can show you a normalized read of your tenant, and how their per-application cost behaves after the tenth application.
Configuration that is portable also stays portable. The same READ and NORMALIZE operations that power a migration also power audits, drift detection, and the next consolidation after the next acquisition. The migration stops being a one-time trauma and becomes a capability you keep.
The playbooks priced for hand-built migrations made sense when configuration was trapped in the console. It is not trapped anymore. Your IdP configuration is data. Price it, move it, and govern it like data.