Waiting to replace your identity provider is cheaper only while three things stay the same: your user count, your customers’ requirements, and the people who understand the current setup. Each of them tends to change, and the cost of staying grows with them while the cost of moving grows only with the number of applications and users you have, so the wait usually ends up more expensive than it looked when you started it. The practical answer is to stop treating the move as “someday” and attach a date and an owner to the decision, which you can still use to decide to stay.
This post is written for a CTO or VP of Engineering whose hosted identity provider (Azure AD B2C, Auth0, Okta or Amazon Cognito, for example) works today but is becoming a worry. It compares the cost of staying with the cost of moving, lists the triggers that should end the wait, and gives you a short review you can put on next quarter’s calendar. It does not argue that you must move, and for some teams staying is the right call.
Why does the move keep getting postponed when nothing is broken?
Moving an identity provider has a visible cost (engineering time, parallel running, some risk to sign-in) and an invisible benefit, because if it goes well nobody notices. Staying has the opposite profile: the costs are spread across invoices, workarounds and slow requests, so no single line item ever looks big enough to act on. Every quarter there is something more urgent, and the decision drifts.
Waiting is not free, because it is a decision to keep paying the ongoing costs of the current setup in exchange for avoiding the one-time cost of change, and that trade can be priced. The rest of this post gives you the pieces to price it.
What does waiting actually mean for the budget?
It means you commit to the current provider’s pricing model, the current workarounds, and the current level of risk for another planning period. For most teams the biggest unknown is not today’s bill but how it behaves when usage grows, which is why the next section starts there.
What does the cost of staying look like over the next two years?
It has three parts, and each grows on its own schedule: the bill itself, the work you do to cover for gaps, and the shrinking pool of people who know the system.
How does per-MAU pricing grow when your users grow?
Many hosted providers charge per monthly active user (MAU), so the identity bill is roughly your active users multiplied by a rate. This post names no vendor prices, because the rates change and differ by tier, but the arithmetic is the same everywhere: if your active users double in two years and the rate per user stays the same, the bill doubles as well. If the rate steps down at higher volume the bill grows more slowly, and if you need a higher tier for features such as enterprise single sign-on it can step up at the same time.
The question to ask is whether your identity cost grows faster or slower than your revenue. If each active user brings in more revenue than the provider charges for them, growth is healthy and you can live with the model. If your product has many low-revenue users (a free tier, a school, a community platform), the identity bill can grow faster than revenue, and that gap is what turns a comfortable setup into a budget problem. The post on modeling per-MAU pricing at scale walks through how to do this with your own numbers.
What workarounds pile up when customers ask for things your provider handles badly?
A common pattern is that a larger customer asks for something the current setup does not do well, such as sign-in through their own company directory, automatic user provisioning, or a custom sign-in domain. The first request gets a workaround: a script, a manual process, or a custom service next to the provider. Each later request adds another, and the workarounds themselves become something your team has to maintain and explain to new engineers.
These costs rarely appear as one budget line, which is why they are easy to miss. A rough way to size them is to count the engineering days spent in the last two quarters on identity-related requests that were not in the plan, and multiply by your loaded engineering cost. That number belongs on the “staying” side of the comparison.
What has Microsoft said about Azure AD B2C support?
If you are on Azure AD B2C, the facts are specific. Microsoft stopped selling Azure AD B2C to new customers on 1 May 2025 and has said it will support the product until at least May 2030, according to the Azure AD B2C FAQ. There is no announced shutoff date, and “at least May 2030” is a floor, not a deadline. Our end of sale and support timeline has the full detail with sources.
What this means for timing is that you are in a planning window, not an emergency. A window is the cheapest time to move, because you can choose the order, run both systems in parallel for as long as you need, and pick a quiet period. Teams who wait until the last year of support may find migration help harder to book and will have less slack if something goes wrong.
What does the cost of moving now look like?
Moving costs people-time, a period of running two systems at once, and some risk during cutover. Its size depends mainly on how many applications, users and integrations you have: whether you move this quarter or in eighteen months, you still need to move your applications, your users and your configuration, and the cost rises only as those grow. The cost of staying rises on more fronts at once (the bill, the workarounds and the key-person risk), which is why the gap tends to widen.
What are the people-time and parallel-running costs?
The main items are the engineering time to move each application, the time to move or re-verify users and credentials, the cost of running the old and new providers together for a while, and the testing and support load during the switch. The full cost breakdown for switching identity providers lists each budget line, including the costs teams forget, so this post does not repeat it. The exit plan and vendor lock-in guide is also useful here, because how portable your current setup is largely determines how big this cost is.
If you are considering Skycloak as the destination, the migration is guided: our engineers plan it with your team and support each stage, and it is staged rather than a single cutover. The Azure AD B2C migration page and the Auth0 migration page describe how that works for each source.
Why is a move on your schedule easier than a forced one?
When you choose the timing, you can start with a low-risk application, learn from it, and move the rest in waves with a rollback for each. When the timing is forced by a deadline, a contract renewal or an outage, you compress the same work into whatever time remains and take on risk you would otherwise avoid.
Which triggers should end the wait?
Three situations come up repeatedly, and any one of them is a good reason to stop drifting and set a date.
A large customer asks for enterprise SSO or user provisioning
If a customer you want to win or keep asks for single sign-on with their own identity provider or automatic user provisioning, and your current setup handles it with a workaround, that is a signal that the next such request will cost more. Compare the cost of the workaround, the deal value at risk, and the cost of a provider that supports it directly.
The identity bill grows faster than revenue for two quarters
One quarter of faster growth can be noise, such as a marketing campaign or a seasonal peak. Two in a row suggests the pricing model is working against you. At that point, put the projected bill for the next four quarters next to the cost of moving and see which line is larger.
The one person who understands the setup is about to leave
If a single engineer carries most of the knowledge about your identity configuration, their departure turns a planned decision into an urgent one. Our guide on how to pick an identity vendor without an identity team covers how to reduce that dependency, and documenting the setup is worth doing whatever you decide.
How do you set a decision date and an owner?
Pick one person to own the decision, pick a date at least one quarter away, and agree on what would change the answer. This turns an open-ended worry into a scheduled review. If you need a written record to get sign-off, the decision memo template for replacing an identity provider gives you the structure.
A three-line review you can put on next quarter’s calendar
Use these three questions at the review, and write down the answers each time:
- What did identity cost us this quarter, and what do we project for the next four? Include the bill and the engineering days spent on workarounds.
- Has a customer, a contract or a team change made the current setup harder to keep? Name the trigger if there is one.
- If we decided to move, how long would it take and who would do it? If you cannot answer it, write that down as a gap.
If the answers show staying is still the cheaper choice, you have a recorded reason and a date to check again. If they do not, you have the numbers to start planning.
Frequently asked questions
When should you replace your identity provider?
Replace it when the cost of staying (the bill, the workarounds and the key-person risk) is higher than the cost of moving, or when a customer requirement cannot be met without a workaround you do not want to keep. Setting a review date is more reliable than waiting for a crisis.
Is it cheaper to wait until Azure AD B2C support ends?
Not by default. Microsoft has said it will support Azure AD B2C until at least May 2030 and has not announced a shutoff date, so there is time, but waiting until the last year gives you less room to run both systems and to schedule around busy periods. The cost of moving mainly depends on how many applications and users you have, so it rises as those grow, but the cost of staying rises on several fronts at once.
How much does it cost to move to a new identity provider?
It depends on how many applications you have, how users sign in today, and how long you run two systems side by side. The cost breakdown post lists the budget lines so you can estimate your own.
What if nothing is broken today?
That gives you good conditions for a planned move. You can choose the order and timing, and you can keep the current provider as a fallback while you prove the new one. The goal of a review date is not to force a move but to make staying a decision instead of a default.