Almost every team that picks a hosted auth provider in year one ends up asking the same question in year three. The bill went from a rounding error to a noticeable line item, the SDK has not gotten any easier to extend, and someone on the engineering team has said out loud that they could probably build it. The question of whether they actually should is a real one, and it does not have a single answer.
This is the operator view of when migrating off a hosted auth provider is the right call, when staying is the right call, and what the actual cost of either path looks like. The vendors will tell you one thing, the loud opinions on Hacker News will tell you another, and neither of those is a substitute for an honest decision based on your specific situation.
What you are actually paying for
Hosted auth providers price aggressively at low volume on purpose. The plan that costs nothing for your first hundred users is the plan that costs five figures a month at fifty thousand. That is not a billing trick. That is the deal. The provider runs a piece of infrastructure that is hard to operate well at scale, and they recover the cost when you are large enough to feel it.
What you get for that money is roughly four things. A working authentication flow that handles the long tail of edge cases you would otherwise have to discover the hard way. A team that owns the security posture of the auth surface, including patching, key rotation, and threat response. A set of integrations with social providers, enterprise SSO, and MFA hardware that you would otherwise have to build and maintain. And the right to point at a third-party brand when an enterprise customer asks how authentication is handled in your security questionnaire.
Each of those has a real value. The question is whether your team can replace them, at lower cost, without giving up something more valuable than the savings.
The signals that mean it is time
A few patterns reliably indicate the hosted provider has stopped paying for itself.
The first is that the bill is climbing faster than your user count. Most hosted auth pricing is per monthly active user, and the price per user does not always go down with volume. If you have grown two times in users and three times in auth bill in the same year, the trajectory is going to keep getting worse, not better.
The second is that the SDK is in your way. Look at your last quarter of engineering work and count the times someone wrote a comment that started with "Auth0 doesn't let us." Each one is real product velocity that you paid the provider to slow down. A few are normal. Many are a signal.
The third is that your customer asks have outrun the provider's roadmap. Enterprise customers ask for fine-grained role models, custom MFA flows, on-premise hosting, regulated-residency data, or specific identity provider quirks. Hosted providers will land most of these eventually, but eventually is not always before your deal cycle. If you are losing deals on auth feature gaps that your team could close, that is a sales problem caused by a build-or-buy decision.
The fourth is that you have outgrown the provider's threat model. Hosted auth providers are great at the common cases. They are not great at the unusual ones. If your business has unusual fraud patterns, jurisdictional constraints, or attack surface that the provider has not seen, you may be paying for protection that does not actually protect you.
The cases where staying is still right
Migrating off auth is not always correct, and the cases where staying is still the better answer are easy to identify when you look at them honestly.
You are pre-product-market-fit. The cost of getting auth wrong, even slightly, is bigger than the cost of overpaying for the next eighteen months. Stay on the hosted provider, ship the product, and revisit the question when you have a customer base worth migrating.
Your team has no security senior. Auth is one of those areas where having a person whose job it is to think about the threat model matters. If your team is light on people who think about authentication and authorization for a living, the hosted provider is doing real work that nobody on your team is qualified to replace.
Your customers care about the brand on the auth questionnaire. Some enterprise customers will not buy from you if the auth is in-house. The customer is wrong to think this way, but they think it anyway, and you have to sell to them.
You are about to be acquired. Custom auth is technical risk on a due diligence call. If a sale is in flight, the worst time to migrate is now.
In any of those four cases, the answer is keep paying. The hosted provider is doing more for you than the bill suggests.
What a migration actually costs
Teams who decide to migrate consistently underestimate the cost. The migration itself is not the hard part. The hard parts are the things around it.
The user data carries assumptions. Hashed passwords with provider-specific algorithms, MFA configurations, recovery codes, social provider linkages, and old session tokens all need a plan. Some of them cannot move at all and require a forced re-auth on a chosen day. The communication and support burden of that day is real.
The integrations carry assumptions. Webhooks, audit logs, role mappings, and customer-specific SSO configurations were all set up over years and are rarely documented. Each of them is a small project to recreate.
The on-call carries assumptions. The team that owned the hosted provider relationship is not the team that owns the new in-house auth. The runbooks, the playbooks, and the incident response have to be rebuilt. The first incident on the new system happens when the playbook is still half-written.
A reasonable budget for a real migration is three months of dedicated engineering time, plus a few weeks of follow-up work in the quarter after launch. Teams who plan for less almost always find more.
A reasonable framework
The decision is mostly about the size of the bill against the cost of the move.
If the bill is small and the team is small, stay. The hosted provider is the right answer for almost every team for the first few years.
If the bill is large and the team is large enough to absorb a real project for a quarter, the migration tends to pay for itself in twelve to eighteen months, with the additional benefit of giving the team back a piece of the product surface that the hosted provider was charging rent on.
If the bill is large and the team cannot absorb the project, the answer is rarely the migration. It is more often a renegotiation with the provider, who would generally prefer to lower your bill than lose your business.
The honest version of this decision rarely fits in a tweet. It fits in an hour-long conversation about the team, the customers, and the next eighteen months. The teams who treat it that way tend to make the right call. The teams who treat it as a vendor fight rarely do.