Upgrading Customer Identity: Why It's Time to Move from Microsoft B2C to Entra External ID

Why this is important.

EEID (Entra External ID) isn’t just a new platform, it’s a strategic shift towards sustainable, future-ready identity architecture. It prioritises long-term stability, automation, and seamless integration with Microsoft Entra. For organisations still relying on IEF (Identity Experience Framework), the next 12-18 months are critical for mapping your migration, before B2C’s end of life becomes an operational risk.

Microsoft’s B2C P1 might be supported until 2030, but the end is in sight, and the direction is clear. B2C P2 is already out of support, and while that didn’t technically retire IEF, it sent a strong signal: legacy B2C is winding down. For teams still running large, customised IEF setups, it’s no longer a question of if you need to migrate, but how soon you can make it happen.

The challenge? IEF gave developers nearly unlimited control over user journeys, with bespoke orchestration, complex claims logic, and chained APIs, powerful but hard to support and develop. EEID (Entra External ID) doesn’t replicate every feature; instead, it provides standardised building blocks, simplified orchestration, and reusable connectors that deliver the same business outcomes with far less effort and overhead. This isn’t just a platform swap. It’s a shift from hand crafted identity solutions to sustainable, future ready architecture.

A common scenario: “Complicated User Flow”

Picture a typical enterprise onboarding flow. A user enters their email address. Behind the scenes, the system checks that address against an external CRM or HR system and then decides what to do next:

If the user already exists, it takes them straight to sign-in.

If they’re a legacy user, they’re redirected to an activation journey.

If they’re brand new, they go down the signup path, collecting extra data like title, country, and department.

From there, it needs to verify both email and mobile, then transform claims (perhaps standardising department codes or adding internal roles) before finally issuing the token back to the application.

Under the old IEF model, this meant crafting 400+ lines of XML just to manage the orchestration. You’d need multiple claims transformations, branching logic, custom REST API calls, and your own HTML templates to make it all look coherent. It worked, and you could customise it perfectly, but it was fragile, opaque, incredibly time consuming and often required a specialist just to make slight changes.

EEID doesn’t remove that complexity; it shifts it. The same business logic still needs to exist, and often it requires far more design. But it needs to be rebuilt using a new architecture, with API connectors, external validation services, and extensibility points replacing your old IEF plumbing. Migrating that logic properly requires a clear understanding of how those older policies were stitched together and how to recreate them safely in EEID. So, although it’s much easier to develop and support once implemented, it needs to be carefully considered.

Rebuilding in EEID

Recreating that same “complicated user flow” in EEID isn’t just a copy paste exercise. The moving parts are still there; they’ve just shifted shape. Instead of XML based orchestration steps, you are making multiple user flows that need to hand user off between each other to replicate the same behaviour. You are also layering in modular API connectors, event driven logic and user flow extensions. Getting a similar experience to behave correctly and securely, means translating all those claims transformations and branching rules into distinct flows that must be carefully chained together using the new EEID building blocks.

Here’s a rough comparison of how each step looks between the two approaches:

EEID reduces the raw XML complexity, but it replaces it with more individual flows that all need to be designed to work together. There’s no single orchestration file anymore, you’re effectively rebuilding your logic as a network of connected experiences. That one file might be replaced by 40+ user flows. Each migration must balance user experience, compliance, and legacy dependencies while ensuring the new setup stays maintainable and extensible.

What You Can’t (Yet) Do in EEID

EEID covers 95% of what organizations used to build in IEF, but not everything makes the jump. The two major limitations today are custom data and custom UI, and both can change how you design your solution, with UI being a potentially dealbreaker.

Custom data: EEID doesn’t support storing arbitrary data or session variables inside the identity layer. You can’t keep temporary claims, lists, or reference data within a flow. Anything dynamic, like tracking multi step progress, complex user states, or workflow decisions, needs to be managed through external APIs, databases, or your application layer. This can mean a massive increase in scope for what was previously a single user flow, as all that context now needs to live outside of EEID and be reintroduced through connectors or pre-/post-logic calls.

Custom UI: This is where most teams feel the impact. EEID no longer supports injecting or replacing HTML templates, JavaScript, or custom layouts. You can theme the hosted experience, including elements like logo, colour, background, but you can’t restyle or change Microsoft managed screens such as email verification, MFA prompts, or password reset. Even if you build a custom front end, those verification moments still hand off to Microsoft’s hosted interface, meaning you can’t fully control the UX.

For organisations where pixel perfect branding, accessibility control, or localised design are key elements, this can be a serious blocker. In those cases, you either design around the managed flows, or consider hybrid patterns, using EEID for identity core while hosting parts of the experience externally, or custom Email/MFA solutions to bypass EEID UI Elements.

These aren’t minor details. They’re architectural decisions that define how far you can take EEID without compromising user experience or compliance. That’s exactly why planning the migration early matters, so that you can find where EEID fits, and where it doesn’t, before you commit.

Antares’ Approach

At Antares, we’ve worked on both sides of the fence. We’ve lived through the era of sprawling IEF policies, the brittle orchestration steps, magic strings, undocumented transformations, and “just don’t touch it” moments that every team eventually ran into. We know what works in the real world, not just what the documentation says.

Our approach starts with intent, not XML. We map what your IEF journeys were trying to achieve, the business rules, validations, and external dependencies, then rebuild those outcomes in EEID using API connectors, extensibility hooks, and the right mix of branding and user experience. The goal isn’t to replicate every line of logic; it’s to deliver the same result in a cleaner, more supportable model.

And because we’re not just an identity team, we would also take care of the integration layer, whether that is CRM, ERP, SAP, Dayforce, SharePoint, or something else your policies were talking to. In most cases, that’s where the real complexity in IEF lived anyway. By handling both sides, we make sure your new identity solution connects to the systems that matter, without losing any of the business logic you’ve already invested in.

Ready to Plan Your Migration?

If your B2C tenant is still running complex IEF policies, don’t wait until Microsoft forces the transition. Now’s the time to review your existing flows, map them to EEID, and start designing a simpler, more maintainable identity experience.

Antares can help you make that shift without losing the flexibility or integrations your business depends on. We’ll translate your custom policies into modern EEID architecture, cleaner, faster, and ready for the future. Just reach out to us: Contact | Antares Solutions