Ask any IT manager what still depends on their domain and you will get a confident answer in under ten seconds: the file server, the Wi-Fi, that one old application. The list is always short, always delivered from memory, and always wrong. Not wrong about what it contains. Wrong about what it leaves out, and the things it leaves out are precisely the things that will fail six weeks after the domain controllers are gone, when the cause is hardest to see. Stage 0 exists because the migration you can afford is the one where nothing surprises you, and the good news is that you do not have to remember anything. The domain remembers for you.
The confidence problem
CatSnackJack enters Stage 0 the way most companies do. The IT manager’s list has three items: FS01 for the shares, the Wi-Fi certificates, and SnackTrack. It is a fine list. It is also missing the two multifunction printers that bind to DC01 over LDAP every night to refresh their address books, the svc-scan account that authenticates from a copier nobody thinks of as a computer, the certificate autoenrollment that quietly renews machine certificates through Group Policy, every device on the network taking its DNS servers from the controllers by way of DHCP, and a scheduled task on SQL01 that runs a nightly export as a domain account. None of those appear on a list built from memory, because memory records what people touch, and the whole point of infrastructure is that nobody touches it.
The failure mode this produces is specific and cruel. The forgotten dependency does not fail during the migration, when everyone is watching and rollback is easy. It fails after, on its own schedule: the next certificate expiry, the next service restart, the next password event, the next morning someone needs the scanned invoices folder. By then the migration is officially done, the team has moved on, and the troubleshooting starts from zero because the thing that broke was never on any list. Every hour spent in Stage 0 is bought back at that moment with interest.
The domain keeps its own inventory
Here is the fact that makes Stage 0 tractable for a small team: every dependency you care about announces itself to the domain controllers, repeatedly, on a schedule. An application that authenticates with Kerberos requests a service ticket, and the ticket request names the service and the client. A printer that binds over LDAP leaves its IP address and the identity it bound with. A machine that still speaks NTLM is logged doing it. A service running as a domain account performs a logon that is recorded like any other. You are not being asked to reconstruct your estate from documentation that does not exist. You are being asked to turn on some instruments that are already installed, wait a month, and read what they wrote down.
You do not need to remember what depends on the domain. The domain has been keeping minutes for years. Stage 0 is learning to read them.
What can pin a domain
The taxonomy is worth holding in your head, because each class has its own instrument and its own disposition later in the series. At the protocol layer there are three: NTLM, which survives in old applications, in anything that connects to a server by IP address rather than name, and in password-based Wi-Fi; Kerberos, which is how every serious Windows application authenticates and which dies with the KDC role the domain controllers carry; and LDAP, the directory lookup protocol that appliances, printers, and older line-of-business software use to find people and validate credentials. At the service layer sit the workloads the domain quietly underwrites: file shares and the home-drive attributes that point at them, print queues, the certificate authority and its autoenrollment, RADIUS authentication for the wireless, and DNS and DHCP themselves, which on most SMB networks live on the domain controllers and are the dependency everyone forgets because they work too well to notice.
Then there are the accounts: services and scheduled tasks running as domain identities, and the managed service accounts whose passwords only a domain controller can serve. There are the devices that are not quite computers, the multifunction printers and badge systems and NAS boxes that authenticate like computers but never show up in anyone’s mental model of the fleet. And there is Group Policy itself, which is less a dependency than a container of dependencies: drive mappings, folder redirection, logon scripts, security settings, each one a small commitment that has to land somewhere when the GPO engine has nothing to talk to.
Every class has an instrument
This is the part that makes the census real rather than aspirational. NTLM has a dedicated audit channel: switch it on at the domain controllers and every NTLM authentication in the domain is logged with the account and the workstation that offered it, and on your newest Windows 11 clients the operating system now goes further and records which process used NTLM and the reason it could not use something better. Legacy LDAP has its own diagnostic events on the directory service log, and they are wonderfully specific: each unsigned or cleartext bind is recorded with the client’s IP address and the identity it bound as, which is exactly the confession you need from the printers. Kerberos ticket events on the domain controllers’ security logs give you a consumer census per application: which service, requested by which client, how often, and with what encryption, which also flags anything still negotiating RC4.
The file server testifies about itself: Windows can name every open session and every file in use on a share, and the directory can list every user whose account still carries a home-drive or roaming-profile path. NPS logs every wireless authentication it processes and names the access point that asked, which is a complete map of what depends on it. The certificate authority can enumerate every certificate it has ever issued, grouped by template, which turns the vague worry about certificates into a short list of populations with expiry dates. And for Group Policy, Intune’s Group Policy analytics will grade every GPO you import against its cloud equivalent, setting by setting, which converts twenty-three accumulated GPOs into a much smaller number that actually do something you still need. If you hold E5, Defender for Identity adds a shortcut: its service account discovery classifies the accounts and draws the source-and-destination map for you. Nothing above requires it.
Cannot move versus has not been touched
While the instruments run, resist the estate’s favorite sentence: that application cannot move. Almost nothing in an SMB estate has actually been tested against that claim. What the sentence usually means is that nobody has looked at the application since it was installed, and the distinction matters enough that Microsoft now documents the markers separating the two. An application is genuinely pinned when it writes to the directory, assumes users live in particular OUs, extends the schema, or hard-codes an authentication path no vendor will ever patch. It is merely untouched when it has a supported modern version nobody installed, a configurable connection string nobody edited, or an authentication mode that was selected in 2016 and never revisited. Stage 4 works that distinction properly; what Stage 0 owes it is the raw list. The genuinely immovable residue at a company this size is usually one to three items. The untouched list is everything else, and everything on it moves with ordinary effort.
Most applications called immovable are merely untouched. The difference is a test, and the test is cheaper than a year of workarounds built to avoid running it.
Thirty days, including a month-end
Run the instruments for thirty days, and make sure the window covers a month-end, because finance systems and export jobs that run monthly are exactly the dependencies memory misses. Thirty days is not ceremony. It is the shortest period in which the quiet dependencies reliably show up: the weekly backup that authenticates as a domain account, the monthly billing export on SQL01, the certificate renewal that only fires when a machine crosses its renewal threshold. A census taken over a weekend proves only that weekends are quiet. And before you trust silence anywhere, prove the instruments work by planting one deliberate legacy authentication and watching it get caught. An instrument that has never caught anything is not evidence of a clean estate. It might just be off.
The gate out of Stage 0
Stage 0 ends with a document, and the gate is checkable. Every NTLM client, every legacy LDAP binder, every Kerberos-consuming service, every domain service account in use, every GPO that still does a job, and every network dependency has a row with a name, an owner, and one of four dispositions: move it, replace it, isolate it, or keep it and say why. The instruments have each caught a planted test, so silence in the logs means silence in the estate. And nothing on the list says unknown. When CatSnackJack’s census closed, the three-item list from memory had become nineteen rows, none of them a surprise anyone would enjoy discovering in month four. The companion build sheet, the AD dependency inventory, stands up every instrument named here and walks the reading of the results, and the census tool runs most of it for you if you would rather not read logs by hand for a month. That is where Stage 0 gets its hands dirty, and it is the last time in this series that guessing is allowed even as a figure of speech.
AD to Azure
‹ Previous: [AD 1] Zero On-Prem AD: The Path, and What It Actually Takes
Next: [AD 2.1] Build Sheet: The AD Dependency Inventory ›
