Every honest zero-AD project arrives at one application that will not leave. The vendor is gone or unreachable, the code is a black box, and it authenticates against the directory in a way nobody can change. This is the article people skip to, hoping for the trick that makes the last thing move, and there is no trick. There is a ladder, four rungs, worked strictly in order, and the discipline of it is refusing to drop to a lower rung until the one above is exhausted. The lowest rung keeps a directory alive and admits, out loud, that you have not reached zero.
First, the test you should already have run
The Stage 0 test is the entry price for this article: most applications called immovable are merely untouched, Microsoft documents the markers that separate the two, and a company that skips the test keeps a domain alive for a problem it could have fixed in an afternoon. Run it before you climb down. For CatSnackJack it is exactly one, SnackTrack, and everything the rest of this article does is aimed at that single stubborn thing.
Rung 1: replace it
The best outcome is that the application goes away. A modern successor that authenticates against the cloud directly, a current version of the same product that speaks a modern protocol, or a business decision to retire a tool nobody will defend once its true cost is named. This rung is a business conversation as much as a technical one, and the migration is the moment to have it, because the cost of keeping the application is about to become visible and quantifiable: it is the reason you cannot turn off a directory. An application that survives that conversation has earned its place on rung 2. Many do not survive it, which is the cheapest possible outcome and the one worth pushing for first.
Rung 2: re-authenticate it, the only rung that actually removes the directory
If the application stays but its authentication can change, this is the rung that wins, and it is the one Microsoft’s own migration guide omits. For the common case of a line-of-business application backed by SQL Server, Microsoft ships exactly the exits that eliminate the directory: SQL Server 2022 can authenticate its users against the cloud directory through Azure Arc, and for the application whose connection stack genuinely cannot be touched at all, the managed cloud version of SQL offers a mode that accepts the old Windows authentication style against cloud identities, which Microsoft describes in its own words as removing this exact migration blocker. Neither of these appears on Microsoft’s headline road-to-the-cloud migration page, whose legacy-application section jumps straight from replacement to keeping a directory in Azure and skips the middle entirely. The skipped rung is the only one that removes the directory, which is why it gets the most space here. The mechanics belong to the Azure SQL series on this site; Stage 4 only owns the decision that this rung is tried before any rung below it. For SnackTrack, this is where the answer lands, with one precondition worth checking early: SQL01 runs SQL Server 2019, and the Arc path starts at 2022, so the project is a database upgrade followed by an authentication change. Weeks of work, against a directory otherwise kept alive for years.
A machine joined to the managed domain cannot also be cloud-joined, and a cloud-joined client gets no single sign-on into the managed-domain island. The tidy picture has no seam.
Rung 3: isolate it
If the application cannot be replaced and its authentication cannot be changed, but it does not strictly need to reach anything beyond itself, isolate it. Strip it to local credentials, put it on a segmented piece of the network with only the specific traffic it needs allowed in and out, and reach its administration through a controlled path with strong authentication in front. You lose single sign-on and central identity for that one box, and you gain a genuine zero-directory outcome, because a machine with local accounts on an isolated segment needs no domain at all. This rung is unglamorous and it is real, and it is the right answer for the appliance that will outlive its vendor and simply has to keep running in a corner. It reaches the series’ actual goal, which the rung below it does not, and that is why it sits above it.
Rung 4: keep a directory, and say so
If none of the above is possible, the application genuinely needs a living directory, and the honest move is to admit that zero AD is off the table while it lives, then choose which directory to keep and for how long. Three shapes exist: keep the existing domain controllers running in a shrunken footprint, run domain controllers on cloud virtual machines, or use Microsoft’s managed domain service. None of these reaches zero AD, and a reader who lands here has not finished, whatever the project plan says. All three reach, at best, zero on-premises domain controllers, never zero directory, and the decision between them turns on whether the application is moving into the cloud and what it needs from the directory once there.
The managed domain service deserves a plain verdict, because it is the option most likely to be oversold to a company at this stage. It is a real product for a narrow case: a workload that has moved into cloud infrastructure, needs only a directory lookup or Kerberos or a domain join, needs no schema extensions, and belongs to an organization that will not operate domain controllers. Outside that case it is a trap, and two findings settle why for the estate this series describes. A machine joined to the managed domain cannot also be cloud-joined, so anything joined to it is cut off from the modern management this whole migration exists to reach. And a cloud-joined client gets no single sign-on into a managed-domain island, because the island holds no account for that client, so the tidy picture of cloud-native laptops beside a small managed-domain server has no working seam between its two halves. Its cheapest tier, at roughly thirteen hundred dollars a year before the network plumbing it also requires, cannot carry custom directory attributes at all. Microsoft itself calls it a transitional capability rather than a replacement for on-premises directory. And I have not found a published account of a domain eliminated by moving to it, which for a product this old is its own kind of evidence. For an application that stays physically on-premises, plain domain controllers on the existing hardware are the better keep, because the managed service adds a network dependency and a rebuild-with-no-way-back without adding anything the on-premises case needs. It is named and declined here rather than omitted, because a reader who has heard of it will otherwise find a vendor page that says yes.
The bridges are not rungs
One clarification that saves a common mistake. There are bridging technologies that let a cloud user reach an on-premises application safely, publishing an internal app to remote users, tunneling to a private resource, letting the cloud issue the ticket a domain honors. Every one of them requires the directory to still be alive, and every one of them retires the day the directory does. They are not steps toward zero, they are ways to make the remaining hybrid window safe and controlled while you work the real rungs above. Presenting a bridge as a step is exactly how a migration stalls: the bridge starts to feel like progress, the directory it depends on quietly becomes permanent, and the company ends up having moved its directory rather than ended it. Use the bridges to buy time and control. Do not mistake them for the exit.
The gate out of Stage 4
Stage 4 is complete when every genuinely immovable application has a decided rung, in writing, and the ones that landed on rung 4 carry a named owner and a review date rather than an open-ended reprieve. A company that reached rung 4 for a real reason has finished this stage correctly even though it has not reached zero directory, as long as it wrote down why and when it will revisit. SnackTrack landed on rung 2, its database upgraded and its authentication moved to the cloud, which left CatSnackJack with no application forcing a directory to survive. That is the good case and it is more common than the fear suggests, because most immovable applications are one test and one re-authentication project away from moving after all. Nothing is left pinning the directory, and Stage 5 goes looking for whatever the controllers are still quietly doing anyway.
AD to Azure
‹ Previous: [AD 5] Replacing the Estate: Files, Print, Certificates, Wi-Fi
Next: [AD 7] What Your Domain Controllers Are Still Doing ›
