The identities moved, the devices rebuilt, the services relocated, the last stubborn application decided. It is tempting to read that as done and reach for the power button. Do not, yet. A domain controller is usually also the quiet host of half a dozen network jobs that have nothing to do with logins and everything to do with the network staying up. Stage 5 is the census that finds those jobs before they find you, the readiness check that stands between a migration that is finished and a migration that only looks finished. It is a short stage, and skipping it is how a clean project ends with a Monday morning outage nobody can explain.
The jobs that were never about logins
On most small networks, the domain controllers quietly run the plumbing. They are the DNS servers every device asks for names, handed out automatically to every machine on the network. They are frequently the DHCP server too, the thing that gives out addresses in the first place. They are the time source the domain trusts. None of these is an identity service, and all of them stop the day the controllers do. This is the category that catches careful teams, because these jobs are invisible precisely by working: nobody thinks about DNS until it is gone, and then everybody thinks about nothing else. Stage 0’s network sweep already found where the devices point for name resolution and addresses, and Stage 5 is where you move those pointers to something that will outlive the controllers, the firewall, the router, or a dedicated resolver, whichever the network already runs. Move them now, with the controllers still up to fall back on, not in the same breath as the decommission.
DNS, DHCP and time are invisible because they work. Nobody thinks about them until a domain controller is off, and then nobody thinks about anything else.
The security surface you are about to lose
If the estate runs Defender for Identity, its sensors sit on the domain controllers, and turning the controllers off turns that detection surface off with them, by design and permanently. Acknowledge it rather than try to prevent it, and note the ordering rule attached: remove the sensor from a controller before you demote it, because a sensor watching a machine that is being torn down generates noise and confusion at the worst possible moment. For a company at this size and licensing tier, the honest truth is usually that this detection was never running, so nothing is lost that was ever had; Entra ID Protection, which covers the cloud side, fires with no sensor and no controller at all. But name it regardless, because a security control that disappears silently is worse than one that disappears on purpose, and the person responsible for detection should hear it from the plan rather than discover it from a gap.
The local administrator password question
One dependency hides inside device management rather than the network: the local administrator passwords on the machines themselves. If the estate managed those with the old domain-joined LAPS, that management moves to Windows LAPS, which backs each device’s local administrator password up to its Entra device object with no directory and no sync involved. Deploy it through device policy before the controllers go, so every machine has escrowed its secret to the cloud rather than to a directory about to vanish. And carry one warning into Stage 6, because it collides with cleanup: deleting a device’s Entra object destroys that device’s escrowed local administrator password and its BitLocker recovery key, irretrievably. The stale-device sweep that feels like tidiness can quietly throw away the keys to a machine, so the rule is to retrieve or confirm that material before deleting any device object, never after.
The last stragglers, read from the same logs
The instruments from Stage 0 are still watching, and now they earn their second use. The NTLM log, the legacy bind events, the Kerberos ticket requests, the file server sessions: read them again, and this time you are not building an inventory, you are confirming a silence. Every authentication still hitting the controllers is a straggler, something that was supposed to have moved in Stages 1 through 4 and did not, or something the original census missed. A service still starting as a domain account, or a scheduled task nobody reassigned. Each one is a small finding and each one is far cheaper to chase now, with the controllers still up, than after they are gone and the symptom is a broken thing with no obvious cause. The goal of this stage is the confident absence of activity: the logs should be quiet, and where they are not, the noise has a name and a plan before you proceed.
The gate out of Stage 5
Stage 5 is complete when the network plumbing has moved off the controllers and been verified working from a real device, when the identity detection surface has been accounted for and its removal ordering understood, when local administrator and encryption material for every device is confirmed present in the cloud, and when the authentication logs are quiet enough that any remaining entry has a name and a disposition. Nothing has been powered off yet, and that is the point. At CatSnackJack, DNS and DHCP had moved to the firewall a week earlier and every device had picked up the change, the identity sensors were confirmed never to have been licensed, every laptop’s recovery material was verified in the cloud, and the logs showed exactly two stragglers: a backup job still running as a domain account, reassigned that afternoon, and one printer nobody had power-cycled since its address book moved. Both handled, the logs went quiet. The controllers are now carrying nothing the business needs, which is the condition Stage 6 requires before it turns anything off.
AD to Azure
‹ Previous: [AD 6] The Application That Will Not Move
Next: [AD 8] The Decommission ›
