Azure AD B2C is end of sale. You have until 2030 to choose well.

Three separate announcements got compressed into one rumour, so start with the dates. All of them come from Microsoft's own B2C FAQ.

So: end of sale, not end of life. Your tenant is not being retired in 2026, and anyone telling you otherwise has read the P2 date as a tenant-retirement date. What you have lost is the roadmap. B2C gets security updates and operational continuity; it does not get new capability, and the product Microsoft is investing in is Microsoft Entra External ID.

That is a real cost, just a slow one. Four years is long enough to plan properly and short enough that a platform decision made today is the one you live with.

This is the part that surprises people, and it is in Microsoft's own B2C-to-External-ID migration guide, not in anyone's marketing.

• Custom policies do not move. The guide maps "Custom policies (XML/IEF)" to "Custom authentication extensions" — a different model, not a converter. There is no tooling that takes your TrustFrameworkExtensions.xml and produces the equivalent.
• Third-party identity providers configured through custom policies are not supported. The guide says so in those words. Social federation has to be reconfigured on External ID's built-in providers, and anything outside that list is a gap you have to design around.
• UI customization narrows. B2C's hosted HTML/CSS page templates map to "user flows with branding" — a company-branding menu rather than pages you author.
• Native authentication is local-accounts only, per the same feature-mapping table. If your mobile apps authenticate against social providers without a browser redirect, check this one first.

None of that makes External ID a bad product. It makes it a new product, aimed mostly at new deployments. The conclusion a B2C customer should draw is narrower and more useful: you are rebuilding your authentication logic whichever destination you choose. Given that, the destination worth picking is the one where the next platform decision is yours.

Keycloak has a direct equivalent for most of what a custom policy expresses, and the equivalents are configuration rather than XML.

What has no clean equivalent: the parts of the Identity Experience Framework that are a programming language rather than a configuration — long claims-transformation chains, and orchestration that branches on computed values. Those become Java.

B2C genuinely wins on things Keycloak cannot match, and they are not small. Zero operational burden. A Microsoft SLA. Deep Azure-native integration — Front Door custom domains, Application Insights, federation to your Entra workforce tenant. And 50,000 free monthly active users, which is more than most applications ever need.

If you are an all-Azure shop running built-in user flows under the free tier, with nobody asking about data residency or source access, sitting tight until 2030 is a defensible engineering decision and anyone selling you urgency is selling you something. Revisit it in 2028.

Keycloak earns the move when at least one of these is true: your logic lives in custom policies and you are rebuilding anyway; you need to run identity somewhere other than Azure, for EU data residency or for a customer's contract; you need federation or protocol support beyond what a successor product supports; or you want the next end-of-sale announcement to be somebody else's problem.

And if you are moving to escape an operations bill, price the operations bill first. Keycloak is a JVM application with a database, a cache and an upgrade cadence; running it well is a real job. That is the argument for managed Keycloak rather than a VM you own — and if you would rather own it, we also support teams who run their own.