Moving off an identity provider costs mostly people and calendar time, not software. For a typical product the biggest lines are engineering hours to rewire each application, a period of running the old and new systems side by side, customer communication and support during cutover, and re-testing every enterprise customer’s single sign-on connection. The software line is usually the smallest one on the sheet. Whether the whole project is a few weeks or a few quarters depends on how many applications sign in today, whether users can keep their passwords, and how much custom login logic lives inside the old provider.
This post is written for the person who approves the budget. If you are the engineer who keeps saying “migration is risky” and needs to turn that into something a finance lead can read, the cost lines below are the vocabulary to use. We do not name vendor prices here, because they change and because your contract is probably not the list price anyway.
Why is the bill for a migration mostly people, not software?
The new provider is rarely the expensive part. Most of the effort goes into the work around it: finding every application that signs in, changing how each one talks to the identity system, moving or recreating user records, and proving to customers and auditors that nothing was lost along the way. Each of those is an engineer’s time, and some of them need a security lead, a support lead or a customer success manager as well.
That is also why a migration estimate that only compares license prices is misleading. Two providers with very different prices can produce similar project costs, and two providers with similar prices can produce very different ones, depending on how tightly your products are tied to the old one.
What line items should a budget approver expect to see?
A reasonable budget has five lines, and each should have a named owner.
| Cost line | What it pays for | Typical owner |
|---|---|---|
| Engineering | Rewiring applications, mapping claims and roles, building or scripting user import | Head of Platform or engineering lead |
| Parallel running | Paying for and operating both systems until the last application has moved | Platform or DevOps |
| Testing | Regression testing of login flows, plus re-testing each enterprise SSO connection | QA lead and the engineers who own those connections |
| Customer communication and support | Notices, help articles, extra tickets during cutover | Support and customer success |
| Security and compliance review | Updating the access evidence, vendor list and risk register that mention the old provider | Security lead |
If a proposal arrives with only the first line filled in, ask where the other four went.
What does a reasonable estimate depend on?
Four inputs move the estimate more than anything else. The first is the number of applications and services that sign in through the old provider, including internal tools and scripts that nobody remembers. The second is the set of login methods in use (passwords, social login, enterprise SAML or OIDC connections, passkeys, one-time codes). The third is the user count, which matters less for effort than for how long a bulk import and a gradual rollout take. The fourth is how passwords are stored and whether the old provider lets you export them, which we cover below because it changes the user experience more than anything else.
What makes a move cheaper or more expensive?
Three things account for most of the variation between a calm project and a painful one.
How many applications and customer-specific connections sign in today?
Every application is a small integration project of its own: a new issuer URL, new client credentials, possibly different claim names, and a regression test. Ten applications that all use the same standard OpenID Connect library are mostly a configuration exercise. Ten applications that each use a proprietary SDK from the old provider are ten code changes.
For a B2B product, add one connection per enterprise customer who signs in through their own identity system. Each of those customers has an administrator on their side who has to update a metadata file or a redirect address, and that coordination is slow because it depends on someone else’s calendar. We look at this more closely under the forgotten costs below.
Do users keep their passwords or reset them?
If the old provider will let you export password hashes in a format the new system understands, users can sign in on the first day without noticing anything. If it will not, you have two choices: ask every user to reset their password, or move users gradually by checking the old system the first time each person signs in. The first is cheap to build and expensive in support tickets and lost sessions. The second takes more engineering and spreads the load out. We describe the trade-off in federate versus migrate for legacy users.
The right answer depends on the provider you are leaving. Some hosted services restrict or do not offer a password hash export, so check this early with your provider, because the realistic plan may then be the gradual approach or a planned reset.
How much custom login logic lives in the old provider?
Custom rules, hooks, scripts and policies are the part of a migration that surprises people, because they are often written by someone who has left and documented nowhere. Azure AD B2C custom policies and Auth0 rules and actions are common examples. Each one has to be read, understood and either reproduced in the new system or deliberately dropped. Budget time for an inventory before you commit to an estimate.
What costs do people forget to budget for?
The three below show up in nearly every project retrospective.
Running both systems side by side
During a safe migration both providers stay live until the last application has moved, so you pay for both and you keep two sets of configuration correct at the same time. Running both is deliberate, because it is what gives you a rollback path. We describe the approach in dual-run IAM migration. The cost is that the project’s end date, not its start date, decides how long you pay twice, so a project that drifts gets more expensive every week.
Customer communication and support during cutover
Even a flawless technical cutover generates tickets, because people notice a changed login page, a signed-out session or a password prompt they did not expect. Plan the notices, the help article and some extra support capacity for the first week after each wave. The cost is small per ticket and noticeable in total, and it lands on a team that did not appear in the project plan.
Re-testing enterprise customers’ single sign-on connections
Each enterprise customer’s connection was configured once, usually under pressure from a deal, and has rarely been touched since. A move changes the service provider details on your side, so every customer connection needs to be checked, and many need their administrator to change something on theirs. If you have forty such customers, that is forty small scheduling problems. Start the list early, and tell customers well ahead of the date.
Identity management as a service, on open source
Skycloak does what Auth0 and Okta do, SSO, MFA, SCIM, audit logs and enterprise federation, on an open source core. Unlimited users and applications on every plan, no charge per monthly active user, and you can export and self-host whenever you want.
What is a phased plan, and who approves each phase?
A phased plan limits how much money you commit before you know more. Each phase ends with a decision that someone with budget authority makes. When you are ready to ask for the first of those decisions, our decision memo template fits the situation, options, cost, risk and timeline on one page.
- Discovery and inventory. List every application, login method, enterprise connection and custom rule. Output: a list and a first estimate. Approver: the budget owner, who decides whether to continue.
- Pilot with one application. Move a low-risk application end to end, including a rollback rehearsal. Output: a measured effort per application, which replaces guesswork in the estimate. Approver: engineering lead and security lead.
- Cutover waves and a rollback window. Move the remaining applications in groups, keeping the old provider live for a defined period after the last one. Output: a decommission date. Approver: budget owner, who signs off on turning off the old system.
The pilot is the most valuable step because it converts “we think it is a few weeks per app” into a number from your own environment. If you are leaving Azure AD B2C, our migration guide and the Azure AD B2C migration page describe the sequence in detail, and there are matching pages for Auth0 and Okta. Migration with us is guided by our team today rather than automated by a tool, so plan it as a project with people on both sides.
How does the cost of moving compare with the cost of staying?
A move is a one-off cost and staying is a recurring one, so compare them over the same period, usually three years, and include the risk of staying as well as the bill.
How do per-MAU pricing models change the yearly cost as you grow?
Many hosted providers charge by monthly active user, so the line grows with usage and not with revenue. A product with many low-revenue users, such as a consumer app, a school platform or a free tier that feeds a paid plan, feels this most. We walk through a simple model in is your identity provider about to get more expensive. The approach works for any vendor: take your monthly active users, project them at two and five times today’s number, and apply your actual contract terms. That gives you the yearly cost of staying, which is the number a migration has to beat.
If you are on Azure AD B2C, remember that Microsoft stopped selling it to new customers on 1 May 2025 and has said it will support existing customers until at least May 2030, according to the Azure AD B2C FAQ. That is a long runway, which means the decision is about planning rather than panic, and it also means you can choose a quiet quarter for the move.
What does a managed provider take off your team, and what stays with you?
A managed identity service takes over the operating work: patching, upgrades, backups, scaling and availability. What stays with you is the configuration of your own login flows, the roles and claims your applications depend on, the customer-facing communication, and the decisions about who gets access. A move to managed Keycloak keeps the open-source software and standard protocols you may already depend on, so your applications are not tied to a vendor SDK again. For a longer look at the build-yourself side of the comparison, see self-hosted versus managed authentication cost. Our pricing page lists plan prices, and the guide for leaders summarises the decision on a single page.
What should you ask a vendor or partner before committing?
These questions bring the hidden costs to the surface before the contract is signed.
- Which parts of the migration do you do, and which parts does my team do?
- Can users keep their passwords, and if not, what is the recommended alternative?
- How long will you support running the old and new systems together?
- What happens to my enterprise customers’ connections, and who contacts them?
- What does the exit look like if I want to leave you in three years? (A provider that is sure of its product should be able to answer this plainly. Our exit plan post lists what to check.)
- How is the work billed if the project takes longer than estimated?
Frequently asked questions
Do we have to move all users at once?
No, and for most products you should not. Moving applications in waves and users gradually (for example when each person first signs in) keeps each step small and reversible. A single large cutover is faster to describe, but it puts every risk into one weekend.
How long should we plan for?
It depends mainly on the number of applications and enterprise connections, so we would be wary of anyone who quotes a number before an inventory. A small product with a few applications and no enterprise connections can reasonably expect weeks. A product with many applications, custom login logic and dozens of customer connections should plan for quarters. A pilot gives you a measured figure to scale from.
What if the project stalls halfway?
The dual-run approach is the safety net here, because the old provider is still live and nothing has been switched off. Set a decision date at the end of each phase, and if the project is behind, decide on the date whether to extend, pause or roll back. The costly outcome is drifting along while paying for both systems with no decision made.
Is it cheaper to stay put?
Staying is sometimes the cheaper choice. If your bill is predictable, your applications are few and nothing about the provider’s roadmap or your customers’ requirements is pushing you, staying can be the right answer, and it is worth saying so in the decision. The move starts to pay off when the recurring cost grows faster than revenue, when a customer requires something the current provider handles badly, or when the provider’s own direction gives you a deadline.