Everything before this stage was reversible. You turned on some auditing, you read some logs, you built a list, and at any point you could have walked away and nothing would have changed. Stage 1 is where that stops being true. Cutting the directory sync is the moment your users stop being copies of on-premises objects and become cloud-native identities in their own right, and the tenant-wide version of that move cannot be undone once it starts. The good news, and it is genuinely new, is that you no longer have to make the irreversible decision all at once. You can rehearse it on three people, watch exactly what happens, and only then commit the rest.
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. 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.
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. If your plan is to cut the sync well before then, this never touches you. But if Stage 1 stretches out, as real projects do, an unattended Connect server can hit that wall mid-migration and hand 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 directory synchronization is off, every user is cloud-managed, the lingering on-premises identifiers have been cleared, the password-expiry setting has been dealt with as a conscious choice, the seamless single sign-on computer account has been removed while a domain controller still stands to remove it from, and sign-in has been confirmed working with the Connect server already shut down so you know nothing quietly depended on it. That last check is the one people skip and regret: prove the tenant stands on its own before you assume it does. At CatSnackJack the Connect server was off, the three pilot users converted a week earlier had behaved exactly like the hundred and thirty-seven that followed, and the only surprise was the one they had rehearsed for, the never-expiring passwords, handled on purpose. The companion build sheet, converting to cloud-only and disabling directory synchronization, walks the pilot, the verification, the tenant-wide cut and the cleanup in order, with rollback shown at the one stage where rollback still exists.
AD to Azure
‹ Previous: [AD 2.2] The Census, Automated
Next: [AD 3.1] Build Sheet: Converting to Cloud-Only and Disabling Directory Synchronization ›
