Field Notes·Issue10·7 Aug

Moving from AD to Entra doesn't fix your identity problem. It relocates it.

An Entra migration moves the apps you already governed onto better infrastructure. The apps you never governed were never in scope, and they're still waiting when the project closes.

Anchit
Anchit·5 min read

Origin

Anchit, one of our co-founders, has taken a version of the same call from four IT leads this year, each of them somewhere between month six and month ten of an Entra migration. The question is always some form of: we did the work, so why does offboarding still take an afternoon.

The cutover lands in September. It was scoped at six months and it took eight, which is about right for six hundred people and a decade of accumulated Active Directory. By the end the team has conditional access, MFA enforced properly, a clean SSO layer, and a directory that nobody has to patch on a Saturday.

Then a contractor rolls off in October, and closing their access eats the rest of the afternoon.

The migration worked. That's the confusing part.


A migration takes the directory you have and moves it somewhere better. Users, groups, application assignments, and the governance you built on top of them. Active Directory governed your Windows endpoints, your file shares, your Exchange environment, the VPN. Entra governs those same things now, from the cloud, with better tooling around them.

What moves is what was already in the directory. Nothing else gets picked up along the way.

The applications that were never in AD were never in scope. The migration team looked at them early, found no clean way to inventory or connect them, and set them aside so the project could ship. That was the right call.

Holding a cutover hostage to the long tail costs another quarter and closes nothing. So those apps went into a future phase.

Procurement kept working the whole time. Eight months is long enough for a customer success platform, a contract review tool legal wanted, two analytics products someone expensed, and a workflow service that operations now runs three processes through. None of them went into AD, because AD was the thing being decommissioned. None of them ended up in Entra either.

So the team finishes with modern identity for the systems that already had governance, and the same manual process as before for the systems that never did. The split was there before the project started. The migration carried it across, and the new dashboard is clean enough that nobody goes looking.


Microsoft isn't overselling here. Entra is infrastructure, and infrastructure governs what connects to it. An application outside the directory sits outside the product's scope by definition, and Microsoft has never claimed otherwise in any document an engineer would actually read.

The overselling happens in the retelling. "Move to Entra and you get modern identity governance" is true in a narrow way that gets heard as a much larger claim. It means the apps you govern today will be governed better tomorrow. It gets heard as: identity is handled.

Entra also carries a cost layer that most teams meet after the cutover rather than before it. The governance features that make Entra look like an IGA tool sit behind a licence upgrade. Then the apps themselves want an enterprise plan before they will expose a SCIM endpoint for Entra to talk to.

Companies running a single identity provider elsewhere pay the SCIM tax once. Entra customers pay it twice, once to Microsoft and once to every app vendor in the stack.


Whether any of this matters at your company comes down to a count almost nobody runs before the project starts: how much of the environment was in the directory to begin with.

It's a simple enough exercise. The reason it gets skipped is that the migration plan is built from the AD export, and the AD export is the thing being migrated. The apps in there are the ones large enough to have implemented SCIM and bought deliberately enough to have gone through procurement. Everything else sits where it always did: the tool a team adopted on a standard plan, the software with a login page and no API, the system that predates the current CTO and whose admin left in 2023.

Run the count against a full inventory rather than the export, and the split usually looks worse than the board slide implies.


The teams that come out of this well treat the cutover as the start of the governance program instead of the end of it.

Entra governs the governed part, properly and permanently. Then, in the same quarter rather than eighteen months later, someone asks the second question: what is outside Entra, and what closes it when a person leaves.

More SSO configuration won't answer it. There's no SCIM endpoint left to configure on those applications and there isn't going to be one.

Governing them means reaching them another way, on a trigger from the HRIS rather than on the day somebody notices. That's the work Iden does, and it begins where the directory stops.

Do the migration. The alternative is a domain controller aging out in a cupboard, and Entra is a better place for the things it can hold.

Just don't let the cutover be the moment you stop asking what it can't.


We'd map what sits outside Entra in your environment, app by app, after the migration is done. No deck. Just the product.