Your Migration Succeeded. The Identity Chain Didn’t.

Identity chain continuity is the thing every migration runbook assumes and almost none of them prove. A migration dashboard can go fully green — compute online, storage attached, network reachable — while the identity chain underneath it is already broken, and nothing in that dashboard will tell you.

The pattern is familiar to anyone who has run a cutover at scale. The migration team declares success. The completion report gets filed. Three days later, a scheduled job fails because a service account can no longer authenticate to a resource it has called successfully for two years. Nobody touched that job. Nobody touched that resource. What moved was the workload. What broke was the authority the workload depended on to do anything once it landed.

This is Part 3 of the Evidence Gap series. Part 1 argued that a recovery plan validated under clean conditions doesn’t prove it survives ransomware-class compromise. Part 2 argued that “the restore worked” is not the same claim as “we can prove the restore worked.” This post makes the same argument about migration: the migration team proved the workload moved. Nobody proved the identity chain survived. Those are different claims, and enterprise infrastructure has been treating them as interchangeable for years.

What the Migration Dashboard Proves

Every migration tool on the market — vMotion, Move Groups, HCX, Azure Migrate, whatever your platform’s equivalent is — is built to answer a narrow question: did the compute artifact arrive intact? That question breaks into three sub-claims, and migration tooling is genuinely good at proving all three.

Compute moved: the VM is running on the target platform, CPU and memory allocated, boot sequence completed. Storage moved: the disks are attached, the data is present, checksums match. Network moved: the interface is up, the VLAN or subnet is correct, the host is reachable.

Those three things are proven. Verified, logged, checkable after the fact. This is virtualization architecture doing exactly what it’s supposed to do — the platform’s job ends at “the artifact exists and responds.”

What the dashboard does not claim — because it was never built to claim it — is whether the identity chain that artifact depends on to actually function came across intact. That’s a separate question, and it’s the one nobody’s tooling is answering by default.

The Identity Chain: What Has to Survive Intact

“Identity chain” isn’t a single object. It’s a set of bindings that all have to hold simultaneously, and any one of them can fail independently of the others.

Machine identity — the computer object, its SID, its trust relationship to the domain or directory. Service identity — the accounts a workload runs as or authenticates with, whether that’s a domain service account, a managed identity, or a cloud IAM role binding. Delegation — the Kerberos constrained delegation or protocol-transition trust that lets a front-end service act on a user’s behalf against a back-end resource. Certificate bindings — the thumbprint-to-service mapping that TLS mutual auth and code-signing checks rely on. Authorization state — the actual permission grants layered on top of all of the above.

This is the layer this site’s Virtualization Control Plane Architecture material treats as part of the control plane, not an add-on to it: identity plane and control plane are the same governance surface, and migration tooling that only validates compute, storage, and network is validating half the control plane and calling it done.

Every one of those five bindings can be individually intact or individually broken. A VM can have perfect machine identity and a completely dead delegation trust. That’s what makes this failure mode hard to catch with a single check — there’s no one place to look.

Where the Chain Actually Breaks

None of these six show up on a migration dashboard, because none of them are things a dashboard is designed to check. Every one of them shows up the first time the workload tries to do real, authenticated work against something it depends on — which is often hours or days after the cutover window closed and everyone stopped watching.

Why the Dashboard Can’t See This

This isn’t a tooling gap that a better dashboard fixes. It’s an architectural boundary. Migration health checks test reachability and boot state — they ping, they poll, they confirm the instance responds. They do not make an authenticated call down the full dependency chain the way the production workload eventually will. A health check that pings a database port proves the port is open. It doesn’t prove the service account trying to query that database still has a valid delegation path to get there.

That’s exactly the mechanism behind what this site has already documented as the migration dashboard illusion: a dashboard reporting success is reporting the thing it was built to measure, and identity continuity was never on that list. The gap isn’t a bug in any specific tool — it’s a category mismatch between what “the migration succeeded” is being asked to mean and what was actually checked.

This isn’t hypothetical. One earlier account on this site tracked the exact failure at a single-VM level — the VM itself was fine, its identity wasn’t. The six failure modes above are that same incident generalized into a checklist instead of a war story.

The Missing Artifact

When a migration completes, what gets retained is: the migration log, the completion report, the cutover timestamp, the validation checklist signed off by whoever ran the runbook. All of that documents that a process executed and that specific technical checks passed.

None of it documents whether machine identity, service identity, delegation relationships, and authorization state survived the migration boundary unchanged. Identity continuity evidence — proof that the identity chain crossed the boundary intact rather than merely that the compute did — is not a byproduct of any of those artifacts. It has to be produced deliberately, and almost nobody produces it, because nobody has been asking for it.

This is the same evidence-gap thesis Part 2 of this series made about disaster recovery, applied one layer earlier. Restore Evidence asked whether recovery could be proven. Identity continuity asks whether authorization survived the recovery — or in this case, the migration — that supposedly succeeded. The migration succeeded. The identity chain may not have. Nothing in the standard artifact set would tell you either way.

Validate the Chain, Not the Instance

The fix isn’t more monitoring on the migrated instance. It’s a distinct verification gate that checks the chain, not the artifact — run as an explicit step, not inferred from the fact that the VM is running.

Dashboard Check	Identity Chain Check
VM powers on and boots	Machine SID matches the pre-migration trusted computer object
Disk attaches, checksums match	Service account authenticates successfully against a real dependent resource, not a health endpoint
Network interface reports up	SPN registrations resolve to the current host and are usable for Kerberos, not silently falling back to NTLM
Host responds to ping/poll	Delegation trust (msDS-AllowedToDelegateTo) is intact end to end for double-hop scenarios
Instance appears in inventory	IAM role or managed identity binding is present and grants the same effective permissions as pre-migration

This is the same distinction Framework #145 (Migration Survivability Test) draws for the broader migration lifecycle — that a successful cutover event and a survivable architecture are not the same claim, and the difference only shows up under the first real incident. The identity chain check is that framework’s logic applied specifically to the authentication and authorization layer, and it connects directly to the anchor thesis of this series: Framework #148’s Recoverability Gap is the distance between a plan validated under clean conditions and one that survives real compromise. An unverified identity chain is exactly that gap, just triggered by a migration event instead of a ransomware event.

This Isn’t a Migration Problem

Identity chain failures aren’t unique to migration. They show up under failover, when a DR environment activates and discovers its service accounts were never re-delegated for the standby site. They show up during cloud relocation, when a lift-and-shift assumes IAM bindings travel with the workload and they don’t. They show up during platform modernization, whenever a control plane changes and nobody re-validates what was implicitly trusting the old one.

Migration just happens to be the event that exposes this failure mode first and most often, because migration is the most common deliberate control-plane change most infrastructure organizations undertake. The underlying problem — that authority chains are assumed to survive events they were never tested against — is the same problem this site’s Data Protection material calls recovery authority fragmentation: identity, credentials, and delegation are personnel- and platform-dependent authority, and that authority doesn’t automatically travel with the system it protects. Treat migration as the special case and you’ll keep discovering this the same way, one broken integration at a time. Treat it as the general case, and you start building the verification gate once instead of relearning it under every kind of infrastructure event that moves a workload’s ground truth out from under it.

Additional Resources