If your identity platform is still running on Azure AD B2C and you haven’t started planning the move to Microsoft Entra External ID, the clock is no longer theoretical. Azure AD B2C Premium P2 was retired on March 15, 2026. Every B2C tenant relying on B2C Premium P2 features—including Identity Protection integration and risk-based Conditional Access policies tied to B2C—lost those capabilities that day. Identity Protection is now exclusively a workforce-tenant feature; there is no licensing path to restore it in a B2C tenant. That’s not a future concern. That’s already happened.
The broader platform hasn’t gone away. Microsoft has committed to supporting Azure AD B2C for existing customers until at least May 2030, and new features simply aren’t coming. You’re running on maintenance mode whether you acknowledge it or not. The question now isn’t whether to migrate—it’s whether you’ll do it on your terms or scramble when the next deprecation notice arrives.
What You’re Actually Migrating From
Azure AD B2C (Business-to-Consumer) is a standalone Customer Identity and Access Management (CIAM) platform that Microsoft built separately from its core Entra identity stack. It stores customer identities in dedicated B2C tenants, handles sign-up and sign-in flows through either GUI-based user flows or XML-driven custom policies (the Identity Experience Framework, or IEF), and connects to social and enterprise identity providers through federation configuration. It works. It’s been working for years. The problem is that “works” and “has a future” aren’t the same thing.
The custom policy system is the part that made B2C genuinely powerful—and the part most likely to cause you grief on the other side. IEF custom policies are XML files that let you define arbitrarily complex authentication journeys: step-up MFA triggered by risk signals, claims transformations across multiple API hops, conditional profile completion flows. Teams that invested in complex B2C policy stacks have real assets that don’t translate directly.
Microsoft Entra External ID is not a renamed B2C. It’s a next-generation CIAM platform built natively on the modern Entra stack—the same foundation that powers Entra ID for workforce identities. That architectural decision matters more than any feature checklist. External ID tenants sit alongside your workforce tenant rather than as isolated islands. Your administrators are guests invited from the workforce tenant. MFA and access policies are managed through Conditional Access, not per-application toggles. The Microsoft Authentication Library (MSAL) is unified—the same application code covers both workforce and customer scenarios without separate SDK paths.
The policy engine is where the philosophical break is sharpest. External ID replaces IEF XML with declarative user flows managed through the Entra admin center, plus custom authentication extensions that trigger at specific event points in the authentication flow. The extensions are event-driven rather than journey-scripted: OnAttributeCollectionStart, OnAttributeCollectionSubmit, and OnTokenIssuanceStart. If your B2C custom policies were doing complex orchestration across those stages, you’ll rebuild that logic—not port it. One-to-one parity isn’t guaranteed, and Microsoft has been direct about that.
The structural difference between the two platforms is easier to see than to describe in prose. The diagram below contrasts the legacy B2C model—an isolated tenant with XML-driven custom policies and a separate SDK path—against External ID’s modern architecture, which sits alongside your workforce tenant and shares its policy and SDK surface:
B2C and External ID share a name lineage but not an architecture. The migration is a platform change, not a rename.
The Decision That Shapes Everything Else
Before you architect anything, you need to answer one question: how many directory objects does your B2C tenant hold?
If the answer is above five million, you’re a candidate for High Scale Compatibility (HSC) mode. HSC mode lets large tenants adopt Entra External ID endpoints while keeping existing users and credentials in place, migrating applications in phases without a bulk user migration upfront. This matters operationally—moving five million user records with credential preservation is not a weekend project.
But HSC mode has real limitations you need to review before committing. Social identity providers (regardless of how they were configured in B2C), passkeys, age gating, and certain Conditional Access scenarios aren’t supported in HSC mode. Enabling HSC mode is a tenant-level change that can only be reversed by opening a Microsoft support ticket. Check your tenant’s directory object count via the Microsoft Graph API directoryObject resource before deciding. And contact your Microsoft account team—HSC mode requires allowlisting, which takes a few days.
For tenants under five million objects, the standard migration path is the right choice—which is to say, the path with the most work and the cleanest outcome. Standard migrations rarely advertise that tradeoff in the documentation.
Translating Custom Policies to Extension Points
If you built on IEF custom policies, this section is where your migration estimate will either hold or fall apart. External ID does not support IEF. There is no import tool that reads your XML and produces equivalent event handlers. What you have instead is a feature-capability mapping exercise.
Start by inventorying what your custom policies actually do. Most IEF implementations are doing some combination of: attribute collection with conditional display logic, API calls to external systems for validation or enrichment, claims transformations before token issuance, and step-up authentication based on risk signals or resource sensitivity. Each of those maps differently to the External ID model.
Attribute collection and validation map most cleanly to External ID’s OnAttributeCollectionStart and OnAttributeCollectionSubmit extension events, which are implemented as Azure Functions. Token enrichment with external data maps to OnTokenIssuanceStart. The custom extension architecture is more constrained than IEF in what it can intercept, but for common patterns it’s workable.
Risk-based flows are the hardest case. B2C P2’s Identity Protection integration—the feature retired in March 2026—required no code: risk signals fed directly into Conditional Access. External ID does not support Identity Protection for external tenant users; Microsoft Graph API identity protection endpoints don’t contain risk score data for External ID user accounts. If your B2C policies were doing risk-based step-up based on Identity Protection signals, you’ll need to replace that with third-party identity risk providers or implement your own risk scoring logic inside the OnTokenIssuanceStart extension. It’s more code, more integration surface, and it’s on you to maintain.
Social identity providers configured through B2C custom policies need to be reconfigured using External ID’s built-in social provider support. Age gating has no current External ID equivalent—if your B2C policies included age verification, that requires a custom solution on the External ID side.
Microsoft’s B2C to External ID migration tool on GitHub handles the user and credential migration, not the policy translation. Don’t conflate the two. (A lot of teams do, and it’s how you end up with migrated users who can’t actually authenticate.)
Moving Users Without Moving Your Users Crazy
User migration is a separate workstream from policy migration, and the credential problem is the part that actually threatens your users’ experience. You can move user accounts with a bulk export and import—that’s straightforward. Passwords are not bulk-exportable from Azure AD B2C. You can’t pull a password hash and load it into External ID. Your choices are: force a password reset on everyone, or implement Just-in-Time (JIT) migration.
JIT migration is the path most enterprise teams choose. When a user signs in for the first time after cutover, the External ID OnPasswordSubmit extension validates their credentials against the legacy B2C tenant, writes the verified password to the External ID account, and flags the account as migrated. Subsequent logins authenticate directly against External ID. Users never see a reset prompt—they just sign in normally, and the migration happens transparently in the background.
Microsoft provides a JIT migration toolkit in the same GitHub repository that includes an export tool for reading users from B2C, an import tool for loading them into External ID, and the Azure Function implementing the JIT credential validation. The toolkit handles Graph API throttling automatically and processes users in configurable batches.
The alternative—B2C-initiated background migration—keeps applications running against B2C while credentials migrate in the background, then cuts over to External ID endpoints. This is operationally heavier than JIT because it requires both tenants to be live simultaneously for longer. JIT is simpler if your scale doesn’t require HSC mode.
Phasing the Migration
Strategic migrations don’t try to move everything at once. A workable phase structure looks like this: first, provision and configure your External ID tenant and validate that the authentication flows you need are achievable before touching anything in production; second, stand up the JIT credential bridge and bulk-import user accounts while B2C handles production traffic; third, migrate applications in cohorts starting with low-risk internal tooling, validating token claims and downstream integrations before each wave; fourth, decommission B2C endpoints as each application cohort completes cutover.
The four-phase sequence below is what most enterprise teams end up running, with a parallel operation window spanning the middle two phases:
The parallel-operation window in phases 2-3 is where most teams under-budget. Plan for months, not weeks.
The parallel operation period—where both tenants are live—is unavoidable unless you’re willing to accept a hard cutover with forced password resets. Plan for it. Budget for it. The vendor demos won’t tell you how long parallel operation actually runs—six weeks is common; six months is not unusual for complex policy stacks.
Validation before each cutover wave should cover end-to-end authentication flows (sign-up, sign-in, password reset), token contents and custom claims against what downstream APIs expect, and any risk-based or step-up scenarios you rebuilt as custom extensions.
What External ID Does Better
None of this migration work is free, which means there needs to be a real payoff. For most enterprise teams, the payoff is in the areas where B2C simply couldn’t keep up.
Key Insight: External ID’s pricing model and B2C both start free for the first 50,000 monthly active users. The cost difference shows up in premium feature pricing and the per-MAU rates above that threshold—worth modeling against your actual usage before assuming the migration is cost-neutral.
The unified MSAL integration eliminates the SDK fork you’ve probably been managing—separate authentication paths for workforce apps versus customer-facing apps, maintained in parallel. With External ID, both scenarios use the same library. Security policy management through Conditional Access is a genuine improvement over B2C’s per-application MFA configuration, because you can apply consistent policy across all your customer-facing applications from a single pane rather than touching each app registration individually.
The admin experience reflects that External ID was designed to be operated by the same team running your workforce identity infrastructure, not a separate specialist. B2C required (and still requires) deep IEF expertise to do anything non-trivial. External ID’s declarative flow model is more approachable, which matters for organizations that have been reluctant to touch B2C custom policies because the original author left three years ago. (Sound familiar? It should.)
External ID also has an active development roadmap—B2C does not. Feature gaps that exist today will close. The corollary is that feature gaps exist today, and if your B2C deployment relies on something that isn’t yet supported in External ID, you’re either implementing a workaround or waiting.
Warning: Before committing to a migration timeline, map every B2C capability your applications rely on against the current External ID feature set. Age gating, specific social identity provider configurations, and some Conditional Access scenarios have known gaps. Build your timeline around those gaps, not around the ideal path.
The Practical Starting Point
The most useful first step isn’t provisioning a tenant or writing an Azure Function. It’s documentation. Pull your B2C configuration—user flows, custom policies, application registrations, API connectors, custom attributes, identity providers, and MFA settings—and build a capability inventory. Then cross-reference that inventory against the Entra External ID supported features list and Microsoft’s official migration planning guide.
| Decision Point | Standard Migration | HSC Mode |
|---|---|---|
| Tenant size | Under 5M directory objects | Over 5M directory objects |
| User migration | Bulk export + JIT credential bridge | Users stay in place initially |
| Credential handling | JIT migration on first login | Phased per-application |
| Reversal | N/A (clean state) | Microsoft support ticket required |
| Feature compatibility | Broadest | Limited (no HSC-mode social IdP, age gating) |
| Setup complexity | Moderate | Requires Microsoft allowlisting |
The table above is a starting point for the conversation with your team and your Microsoft account team. The right approach depends on tenant size, custom policy complexity, social identity provider dependencies, and how much parallel operation your infrastructure budget can absorb. Most teams underestimate the inventory step—block two weeks for it before you touch a single tenant setting.
What you can’t do is treat May 2030 as your planning horizon and assume nothing changes before then. The P2 retirement showed that sub-platform capabilities can be pulled ahead of the overall service end date. Migrations that run on schedule tend to be migrations that started planning early.
Where to Start the Migration
Azure AD B2C served as the primary Microsoft CIAM platform for nearly a decade, and the workloads running on it are real, production, and business-critical. The migration to Entra External ID is genuinely complex—not because Microsoft made it hard, but because CIAM implementations accumulate custom logic over time and identity systems are the kind of thing you can’t test adequately in staging.
The core decisions are: which migration path (standard or HSC), how you handle credentials (JIT is the right answer for most organizations), how you translate custom policy logic to event extensions, and in what order you migrate your application portfolio. Each decision is answerable with the information Microsoft has published. What takes time is the inventory work, the gap analysis, and the validation before each cutover.
Start with the audit. The code comes later.
