Everything before this stage was reversible. Stage 1 is where the one-way door comes into view, and where you learn to walk through it a few people at a time. Converting a synced user to cloud-managed is now a supported, reversible, per-user operation, which means the first cohort is a rehearsal you can take back. The tenant-wide cut that retires the sync engine is still one-directional and still the point of commitment, and it no longer belongs here: it waits at the far end of the journey, after the devices, the services and the stubborn application have stopped needing the directory, and Stage 5’s census says so in writing. Stage 1 builds the mechanism and proves it. The door closes last.
The reader is already most of the way here
CatSnackJack authenticates with password hash synchronization, and that matters more than it looks. Of the ways a hybrid tenant can sign in, password hash sync is the only one with no live on-premises dependency at the moment of authentication. Pass-through authentication needs an agent and a reachable domain controller for every single sign-in; federation needs the AD FS farm standing and healthy. A tenant on either of those has an identity migration to do before it can even think about cutting the sync. A tenant already on password hash sync, like this one, has nothing to change about how people sign in. The hashes are already in the cloud, sign-in already succeeds when the domain controllers are unreachable, and that is why this reader can approach Stage 1 as a data-ownership change rather than an authentication project. If your estate still runs pass-through or federation, move to password hash sync first and let it settle; that is its own well-documented piece of work and it is the prerequisite for everything below.
What the sync actually is, and why cutting it is a door
Every synced user in your tenant is, in a real sense, a shadow. The master copy lives in Active Directory, and the Connect server projects it into Entra on a schedule. The cloud object carries an immutable link back to its on-premises original, and a set of attributes it is not allowed to edit because they belong to the source. This is why you cannot manage a synced user’s core properties in the cloud: the cloud is not where they live. Cutting the sync is the act of making the cloud copy the original, promoting the shadow to the thing itself. Once that promotion happens tenant-wide, there is no on-premises master to fall back to, and the operation that performs it is explicitly one-directional. That is not a flaw to engineer around. It is the whole point. You are not disconnecting a sync, you are transferring the authority for who your people are from a directory in your building to a directory in the cloud.
Authority does not live in two places at once. That is the whole reason the tenant-wide cut runs one way and cannot be called back once it starts.
The change that makes this safe: per-user first
Until recently the only way through this door was the tenant-wide switch: turn off directory synchronization for everyone at once and let the backend convert every object in a single operation that runs for up to seventy-two hours and cannot be cancelled. Synchronization can be turned back on after a seventy-two hour hold, and turning it back on starts a full synchronization that re-matches every object it finds. What it cannot do is put back anything removed after the cut, an account, an attribute, a sync rule, a forest, so treat re-enable as a second migration rather than an undo. That worked, but it asked you to trust a hundred and forty conversions you had never seen. The newer mechanism, Source of Authority transfer, changes the shape of the risk entirely. It converts one object at a time, on demand, while sync keeps running normally for everyone else, and it is reversible. A transferred user becomes cloud-managed immediately; if something looks wrong, you hand authority back and the sync engine takes the object over again on its next cycle. This is the feature that lets you turn an all-or-nothing gamble into a rehearsal, and it is the reason Stage 1’s build sheet is written as a pilot wave rather than a single cut.
Two honest limits on it. It is driven through the Graph API and there is no point-and-click experience in the admin center yet, so the pilot is a scripted operation rather than a portal one; the build sheet handles that. And a user you transfer who still genuinely needs an on-premises presence, a lingering resource that reads their account directly, keeps whatever on-premises attributes that resource depends on, which you now maintain by hand rather than by sync. For most users at a company like this, the answer is that nothing on-premises needs them anymore, which is exactly what Stage 0’s inventory told you.
The order Microsoft’s own guidance sets
Microsoft’s guidance for this migration is application-centric, and it is worth taking at face value because the prerequisites enforce it. A user cannot be transferred while anything still authenticates them by password against the domain; the transfer is simply not supported for them until that dependency is gone. A user who still needs Kerberos resources crosses only with passwordless sign-in, cloud Kerberos trust, and their AD account left standing behind them. Read those conditions together and the sequence writes itself: the estate work in the stages ahead is what manufactures eligible users, cohort by cohort, and identity conversion follows that readiness rather than leading it. Convert the people Stage 0 cleared today, convert each department as its file shares, applications and Wi-Fi stop asking the domain about them, and let the sync engine keep running for everyone not yet ready. The alternative, converting everyone first and modernizing afterwards, leaves a tenant full of cloud-managed users whose password changes no longer flow to the directory their file server still checks, and the first cloud password change turns that arrangement from theoretical into a help desk queue.
Groups go first, and this is the piece most plans miss. Microsoft recommends transferring a group’s authority ahead of its members, because memberships and application assignments hang off the groups and testing against them only works once they are cloud-owned. The transfer covers security groups cleanly; distribution lists and mail-enabled groups become Exchange-managed and read-only in Entra, so they wait until nothing on-premises still manages mail objects; nested groups convert one at a time from the bottom of the hierarchy up; and where something on-premises still consumes a group, a cloud-owned group can be provisioned back down into the directory for as long as the directory lives. None of this is exotic, but all of it is sequencing, and it belongs in the same cohort plan as the users.
What converts cleanly, and what lingers
When an object converts, most of it just works. The object keeps its identifier, so group memberships, application assignments, licenses and mailbox all stay attached; a converted user does not notice anything at their desk. The shadow attributes that tied the object to its on-premises master are cleared, and the object becomes fully editable in the cloud. What does not clean itself up is worth knowing before you meet it. Some of the on-premises linkage identifiers can linger on the object after a tenant-wide cut, and a stale one can confuse a later device operation, so cleanup is a real step rather than a courtesy. And there is one specific trap with a long tail: synced users almost always carry a setting that makes their passwords never expire, because expiry was being managed on-premises, and cutting the sync does not clear it. Convert without addressing this and you have a hundred and forty cloud accounts with passwords that never expire and no on-premises policy left to force a change. It is not a disaster, it is a decision you now have to make deliberately in the cloud instead of inheriting it.
The Exchange question, answered honestly
For an Exchange Online tenant with no on-premises Exchange server left, the mail attributes are the one place people expect trouble, and the honest answer has a moving part. Managing Exchange properties on a synced user has historically required editing them on-premises and letting them flow up. Microsoft now lets you move that authority to the cloud per mailbox, and the first half of that capability is generally available. The half that writes cloud changes back down to Active Directory for anything still reading them on-premises is, as of this writing, still in preview and has already slipped past one target date, so treat it as preview and check its status before you lean on it. For this reader it mostly does not bite: with no on-premises Exchange and users heading for cloud-only anyway, the mail attributes stop mattering the moment the objects convert, and the schema extensions Exchange left in your directory years ago are inert and die quietly with the forest. Nobody needs to remove them and nothing depends on them.
The clock the sync engine is holding
There is one date in this stage that is not yours to set. On September 30, 2026, Microsoft enforces a minimum version on the sync engine, and any Connect server older than the floor simply stops synchronizing until it is upgraded. Under the sequencing this series recommends, that date is probably yours. The sync engine runs until the Stage 5 census clears the tenant-wide cut, which means it runs through the device rebuild, the service moves and whatever the stubborn application costs you, and a migration measured in quarters spans this deadline rather than beating it. An unattended Connect server sitting through those cohort waves hits the wall mid-migration and hands you an outage you did not schedule. The move is simple, upgrade the Connect server to a current build before you start the stage, and the deeper lesson is the one this whole series keeps returning to: the hybrid state you might be tempted to sit in comfortably is a maintained product with enforcement dates, not a stable resting place. The sync you are about to retire would have demanded attention on its own schedule whether you migrated or not.
The gate out of Stage 1
Stage 1 is complete when the pilot cohort is cloud-managed and verified, when rollback has been rehearsed on a real user and watched to complete, when the groups those users hang off have crossed ahead of them, and when the cohort plan for everyone else is written down against Stage 0’s inventory, each wave tied to the stage that clears its dependencies. What Stage 1 deliberately does not include is the tenant-wide cut. That single seventy-two hour operation waits until the census in Stage 5 reads quiet, when the last cohort converts, the seamless single sign-on computer account comes out while a domain controller still stands to remove it from, and the sync engine retires with nothing left depending on it. At CatSnackJack the three pilot users converted, one was deliberately rolled back and re-converted to prove the path, and the remaining hundred and thirty-seven were mapped into cohorts that follow the devices and the services out. The companion build sheet, converting to cloud-only and disabling directory synchronization, walks the group transfer, the pilot, the verification, the cohort expansion, and the eventual tenant-wide cut with its census gate stated in front of it.
AD to Azure
‹ Previous: [AD 2.2] The Census, Automated
Next: [AD 3.1] Build Sheet: Converting to Cloud-Only and Disabling Directory Synchronization ›
