Azure AD B2C end of sale: what it means for customer login
Azure AD B2C stopped being sold to new customers on May 1, 2025, according to Microsoft's overview of Azure AD B2C. If your team runs customer sign-in on it, the decision is no longer whether to buy it for a new project but how to keep existing tenants running on a path you can defend. Microsoft's own route is Entra External ID, which is sold separately from Entra ID P1, P2 and Suite and whose core features are free for the first 50,000 monthly active users, per Microsoft's pricing page. The self-hosted route is Keycloak or ZITADEL, both of which can serve customer identity inside infrastructure you control. The end of sale does not switch off existing tenants, so the real work is a migration project with a timeline, not a procurement decision.
Treat the existing tenant as a data and journey inventory before you choose a target. Confirm with Microsoft what remains supported for your tenant and contract, and list each user flow, custom attribute and social identity provider in use. Azure AD B2C stores up to 100 custom attributes per user, so check which of those fields your applications actually read. Establish whether passwords can be exported at all, since that determines between a bulk migration and just-in-time migration, which ZITADEL documents as one of its migration approaches. Ask the vendor or your partner to confirm which of these steps apply to your tenant, because the answer changes the cost and the cutover plan. Keep the customer-facing login available throughout, and plan a rollback path for each application you move.
What a customer identity move must preserve
A move off Azure AD B2C has to keep every login path working for existing customers while the user journeys change underneath them. The four cards below cover the protocol surface, the attribute model, the regional storage rules and the credentials and social logins that customers already depend on.
Protocol compatibility with every relying party
Azure AD B2C supports OpenID Connect, OAuth 2.0 and SAML, so each application that signs customers in uses one of these protocols. Before choosing a target, list every relying party, its protocol, its token claims and its redirect URIs. Confirm that the replacement issues the same claims and accepts the same client settings for each app, because a claim mismatch breaks sign-in even when the login page works. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and ZITADEL implements OpenID Connect, OAuth 2.0 and SAML 2.0, so both can cover the same protocol set.
Custom attribute model and its limits
Azure AD B2C can store 100 custom attributes per user, and many B2C tenants use them for loyalty tiers, consent flags or account references. Export the attribute list from the tenant and map each one to a user attribute, a claim or a role in the target system. Ask whether any attribute is read only at sign-in and whether it must be written back to a downstream system. Attributes that exist only in custom policies often have no direct equivalent and need a planned home before cutover.
Regional data storage requirements
Azure AD B2C runs worldwide in the Azure public cloud, and Microsoft suggests external user stores where policies require regional or on-premises storage of personal data. If your data protection rules fix where customer records live, self-hosting moves that decision to you. Confirm the region of each database, backup copy and log sink, and document which country or entity controls the infrastructure. Keycloak and ZITADEL both run on a database you choose, with PostgreSQL among the supported options, which makes the storage location a deployment decision rather than a vendor setting.
Credential and social login continuity
Customers expect the same password, passkey and social login after the move, and a change in identity provider can force resets if the migration does not carry credentials. Confirm whether the source exposes password hashes and on what terms, since that determines whether users keep their passwords. For social providers, plan the redirect URI changes at Google, GitHub or Apple, because those consoles must accept the new callback before users are switched. ZITADEL documents migration guides from several platforms and supports passkeys with password fallback, which gives customers a path that does not depend on a reset.
How Microsoft's External ID path differs from self-hosting
Microsoft's suggested successor for customer login is Microsoft Entra External ID, which is sold separately from Entra ID P1, P2 and Suite. Its core features are free for the first 50,000 monthly active users, after which pricing follows Microsoft's pricing page, so the reader should confirm the tier that applies to their user counts and which features sit outside the free core before comparing it with a self-hosted plan. Microsoft operates the service in its public cloud, so the team does not choose the hosting region, run the servers or patch the platform. Confirm with Microsoft where tenant data is stored and whether that location meets the organization's data residency policy.
A self-hosted option changes who holds that control. With Keycloak or ZITADEL running in the organization's own cloud account, data centers or network, the team chooses the data location, the database (ZITADEL uses PostgreSQL 14 through 18, Keycloak supports several production databases), the upgrade timing and the backup design. That control comes with recurring operating work: high availability, monitoring, certificate management and security patching. The cost also changes shape, since the license fee moves to infrastructure, staff time and any support contract, and those are the items to put into a written scope for a quote.
Do not assume feature parity with External ID or with the Azure AD B2C user journeys. Before committing, map each journey, custom attribute (Azure AD B2C stored up to 100 custom attributes per user) and social login to the target platform, and confirm with Microsoft which External ID capabilities replace them. Keep a list of anything that cannot be mapped, such as a custom policy step with no equivalent, and plan a migration test with a sample of real accounts before cutover.
Which self-hosted option fits which customer identity need
This table compares Keycloak and ZITADEL against the requirements that usually drive a customer identity replacement for Azure AD B2C. Read each row as a question to answer in a proof of concept, since several cells describe what each product supports rather than how much work your journeys will take.
| Requirement | Keycloak | ZITADEL |
|---|---|---|
| Protocol support | OpenID Connect, OAuth 2.0 and SAML 2.0, plus identity brokering and user federation | OpenID Connect, OAuth 2.0, SAML 2.0, SCIM 2.0 and LDAP, with a device authorization grant |
| Multi-tenant structure | Realms isolate users, clients and policies; confirm how many realms your tenant model needs | Instances give full data isolation, organizations hold users and projects, and each organization can use its own identity provider |
| User federation | Built-in federation with existing LDAP and Active Directory servers | Federates with Entra ID, Okta, Google, GitHub, LDAP, Keycloak and any OIDC provider; just-in-time migration is documented |
| Passkeys | Confirm passkey and WebAuthn flows in your target version before committing | Passkeys based on FIDO2 and WebAuthn, with fallback to password login |
| Database options | Wider list including MariaDB, MySQL, Oracle, SQL Server and PostgreSQL 14 to 18 | PostgreSQL 14 through 18 only |
| Licensing | Apache License 2.0, a CNCF incubating project | AGPL-3.0 for core, Console and hosted login; Apache 2.0 for APIs, SDKs and Helm charts |
| Journey customization effort | Authentication flows and themes are customizable, but custom sign-up and profile journeys need testing against your current Azure AD B2C policies | Login experience and flows are configurable, but B2C custom policy equivalents need testing against your journeys |
How to deploy and cut over from Azure AD B2C
This sequence moves customer login from Azure AD B2C to a self-hosted Keycloak or ZITADEL instance in a controlled order, so each journey, attribute and identity provider is proven before any application stops using the old tenant.
Inventory policies, journeys, attributes and providers
The identity owner and application leads list every user flow, custom policy, API connector, custom attribute and social or enterprise identity provider in the B2C tenant. Export the tenant configuration and map each item to a target equivalent in Keycloak (authentication flows, identity brokering, user attributes) or ZITADEL (instances, organizations, identity providers). Note which of the 100 custom attributes per user Microsoft documents are actually in use, and which applications call them. The step is done when every journey and application has a named owner and a mapped target, and the gaps are written down for review.
Choose the target platform and environment
Decide between Keycloak and ZITADEL using the multi-tenant model, protocol needs and team skills documented in the earlier comparison sections. Confirm the hosting location, since Azure AD B2C runs in the Azure public cloud and external user stores are the usual route for regional data storage rules. Ask your platform team to confirm which PostgreSQL version is available, because Keycloak and ZITADEL both need a supported database. The step is done when a written decision record names the product, the hosting location and the accountable owner.
Deploy on Kubernetes or Docker Compose
For a production cluster, install the Keycloak Operator through Operator Lifecycle Manager or with kubectl, or install the official ZITADEL Helm chart, and create the Keycloak or ZITADEL resources in a non-production namespace. Smaller setups can run Docker Compose, but treat that as a lower availability option and confirm the high availability design against the Keycloak documentation before going live. Set the Keycloak Operator to manual approval mode so upgrades are applied only after review. The step is done when a non-production instance starts, serves its admin console and passes a test login from a sample application.
Plan the database schema migration
Keycloak migrates its schema automatically at startup by default. For large deployments, the upgrading guide describes applying the SQL manually, which your database team can review before any change. Set up backups before the first start and test a restore, since the Keycloak export and import commands are documented as limited for backup and restore and require all nodes to be stopped. ZITADEL uses PostgreSQL 14 through 18. The step is done when the database team signs off on the migration approach, the backup and restore test has passed, and the rollback path is documented.
Migrate users with just-in-time or bulk import
Choose just-in-time migration, where users move on first login, or a bulk import, or a combination. ZITADEL documents migration guides from Auth0, Keycloak and Firebase, and just-in-time approaches. Confirm with the Azure AD B2C administrators whether password hashes can be exported, since this affects whether users must reset passwords. Run a parallel period in which the old and new logins both work for a pilot group of test accounts, and compare token claims, attribute values and social login results. The step is done when pilot users complete every journey on the new platform and claim differences are logged and resolved.
Cut over applications in stages
Repoint one application at a time from the B2C authority to the new issuer, starting with a low-risk application. Update redirect URIs, client secrets, scopes and token validation in each relying party, and check that custom attributes arrive where the application expects them. Keep the B2C tenant active for rollback until every application has run successfully on the new platform through its normal business cycle. The step is done when each application has a signed-off change record and its logs show successful sign-ins against the new issuer.
Retire the Azure AD B2C tenant
After the rollback window closes, the identity owner exports the final configuration and audit records you need to keep, then removes application registrations, user flows and the tenant itself under your organization's retention policy. Confirm with legal and compliance that retained records meet your obligations. Record the final state in the runbook, including the monitoring, backup schedule and upgrade cadence for the new platform. The step is done when the tenant is no longer used by any application, the retained records are stored, and the operations runbook is handed to the platform team.
Evidence auditors and regulators ask for during the move
Auditors and regulators rarely accept a migration on the strength of a plan alone. The evidence below connects the decision record, the data flows, the recovery tests, the logs and the reconciliation of users and sessions. DeployOpen prepares this evidence inside your environment, but independent auditors and certification bodies issue any audit report or attestation.
Decision record for the end of sale
Record why the Azure AD B2C end of sale forced a decision, which Microsoft path you assessed (including Microsoft Entra External ID and its separate pricing), and why Keycloak or ZITADEL was chosen. Include the owner, the date of the decision and the scope of applications covered. Reviewers look for a traceable link between the business need and the chosen platform, and for the alternatives you rejected and why. Confirm the Microsoft position against the current Microsoft Learn overview before you sign the record.
Data flow and residency documentation
Map where customer profiles, passwords or password hashes, custom attributes and social login tokens sit before and after the move. Azure AD B2C stores data in the Azure public cloud by default, so note any external user store you add for regional storage rules. Show which self-hosted region, database and backup location hold each data class, and which third parties still receive data, such as social identity providers.
Backup and restore test results
Keep dated restore tests for the Keycloak database and realm configuration. Keycloak's realm export and import with kc.sh is documented with limitations as a backup mechanism, and all nodes must be stopped while it runs, so plan a maintenance window and record it. Test restores into a separate environment, record the time to recover and the users and clients verified, and keep the database backups as the primary recovery source.
Access and change logs for the new platform
Auditors will ask who can administer the Keycloak or ZITADEL instance, who changed realms, clients, flows or identity providers, and whether those changes were approved. Retain admin event logs, the audit trail of configuration changes in your Git repository or Operator manifests, and the approval records for upgrades. Confirm which logs Keycloak or ZITADEL writes by default and where your SIEM receives them.
Migration reconciliation reports
Reconcile user counts, active accounts, linked social identities, custom attribute values and application client registrations between Azure AD B2C and the target. Record exceptions, such as accounts that could not migrate because password hashes were unavailable, and how each was handled, for example by just-in-time migration or a reset flow. Sign-off by the business owner should follow each reconciliation run, and the report should be retained with the cutover record.
Cost, effort and what the migration needs from your team
What drives the cost of moving off Azure AD B2C?
The cost follows scope more than the software, because Keycloak and ZITADEL are both open source and carry no license fee. The main drivers are the number of user journeys you must rebuild, the volume of users and sign-ins your servers must carry, how many custom attributes you need to map, how many social and enterprise identity providers you connect, and how much high availability and backup you require. Each of these changes the infrastructure size and the engineering hours. Ask any provider to price these drivers separately so you can see which decisions move the total.
- Compute and database hosting in your own cloud account or data center
- Engineering time for journeys, attribute mapping and identity provider connections
- Testing, cutover and user communication
- Ongoing operations, upgrades and support
Which costs are one-time and which recur after go-live?
One-time costs cover discovery, design of user journeys, building and testing the new login flows, migrating user data and cutover. Recurring costs cover the servers and database that keep running, backups, monitoring, security patching, Keycloak or ZITADEL version upgrades and the support you buy. Keycloak ships four minor releases a year according to its own plan, so budget for regular upgrade work rather than a single event. Ask the provider to separate these two groups in the written quote so you can compare the run cost with your current Azure AD B2C bill.
How long does a migration from Azure AD B2C usually take?
Duration depends on scope, and no fixed timeline applies to every tenant. A small tenant with one sign-up flow, one identity provider and few custom attributes is a far smaller job than a multi-brand customer base with several social logins, legacy password hashes and regional data rules. Timing also depends on how quickly your team reviews designs and how much testing your applications need. Ask for a timeline in the written scope that lists the milestones, the dependencies on your team and the testing period before cutover.
What does our team have to provide for the migration?
Your team owns the business decisions and the access that outside engineers cannot supply alone. Expect to provide a list of applications and their login requirements, the user journeys and branding to reproduce, the custom attributes in use and their meaning, the social and enterprise identity providers you rely on, and the credentials for your Azure AD B2C tenant. You also need a named owner who can approve design and test results, plus a staging environment where the new login can be exercised. Confirm in advance who handles DNS, certificates and the cloud account that will host the service.
Can our own engineers migrate off Azure AD B2C without outside help?
A capable platform team can do it, provided it has experience running a production identity service and enough time to take on the work alongside its normal duties. Keycloak and ZITADEL both document migration approaches, and ZITADEL lists guides for moving from Auth0 and Keycloak, along with just-in-time migration. The harder parts are secure handling of user credentials, high availability design, and testing every journey end to end. Consider whether your team can staff the build, the cutover and the first upgrade cycle, and whether anyone will be on call for the service afterward.
Which database and high availability choices change the price?
The database and availability design change both the initial build and the recurring run cost. Keycloak supports PostgreSQL 14 to 18 and several other production databases, and its high availability designs require a synchronously replicated database. ZITADEL self-hosts on PostgreSQL 14 through 18 and recommends a Kubernetes cluster with the official Helm chart for high availability. Choosing a managed database service or running your own replicas affects staffing and backup effort. Ask the provider to state which database, how many nodes and which availability zones the quote assumes.
What should we ask for in a fixed-scope written quote?
A fixed-scope quote should name the deliverables, the user journeys and identity providers in scope, the environments to be built, the testing and cutover steps, and the handover documents. It should also state what is excluded, such as application code changes or work on Azure AD B2C itself, and which party provides hosting. DeployOpen works from a written scope agreed before work starts and does not publish a price list, so a quote follows from that scope. Ask for the assumptions behind each line, the acceptance criteria and how changes to scope are priced.
How DeployOpen approaches a customer identity migration
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted identity platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an isolated network. For an Azure AD B2C replacement, that work usually covers the realm or instance layout, the Keycloak or ZITADEL deployment, the database and high availability design, the federation links to existing identity providers, and the rebuilt user journeys. Most engagements are fixed-scope, so the systems to be built, the user journeys to be moved, the social and enterprise identity providers to be connected and the cutover approach are agreed in writing before work starts. Confirm with any implementation partner whether the first deliverable is an inventory of your B2C policies, applications and custom attributes, since that inventory sets the rest of the scope.
A customer identity migration carries risks that are specific to the platform being left. Plan for the export gap first: Azure AD B2C does not give you a clean path to exporting password hashes, so confirm early what user data can leave the tenant and whether users will need to reset credentials or be migrated just in time. Other items to scope include the custom attributes stored per user, the sign-up and profile edit user flows, token claims consumed by your applications, and any external user stores already in use. The Keycloak database must also be sized and made highly available before cutover, and the backup and restore process for realm data should be tested, because realm export and import have stated limitations as a backup mechanism.
Security testing and compliance evidence are separate deliverables and can be scoped alongside the migration. DeployOpen can run application and API security testing against the new login flows, test the identity platform configuration, and prepare the operational documentation and control evidence that your own auditors will review. DeployOpen does not issue audit reports or certifications, so confirm which independent assessment your program requires. Ongoing upgrades, monitoring and continuous testing after go-live are available under a retainer, which is useful because Keycloak and ZITADEL both release on their own schedules and need to be kept current.
How DeployOpen runs this migration under your constraints
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For Azure AD B2C end of sale, the work starts with a written scope that fixes which user journeys, attributes and social logins move, and which stay as they are until cutover.
How we scope
- Inventory every user journey, custom attribute and social login currently running on Azure AD B2C before choosing Keycloak or ZITADEL.
- Confirm where customer identity data must be stored, since Azure AD B2C runs in the Azure public cloud and regional rules may require a different location.
- Agree deliverables, timelines and responsibilities in writing before work starts, because most engagements are fixed-scope.
How we build
- Configure the target identity platform, its database and high availability design, and the user journeys in a staging environment inside your infrastructure.
- Plan how existing users move across, including whether just-in-time migration or a bulk export and import fits your user store and password handling.
- Run security testing against the login flows, APIs and social login integrations before any customer traffic reaches the new platform.
How we hand over
- Document the realm or instance configuration, identity provider connections, backup and restore steps, and the cutover runbook your team will use.
- Deliver evidence and control documentation for your compliance assessors, noting that DeployOpen prepares these materials but independent auditors issue any reports.
- Train your administrators on daily operations, including user administration, client registration and upgrade procedures.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing separately from the migration.
- Agree a patching and upgrade approach with your team so that platform releases are reviewed and tested before they reach production.
- Ask for the support scope, response expectations and escalation path in your quote, since these depend on the retainer you choose.
