Syncing one on-prem AD to a new tenant: hybrid identity and Entra Connect in a tenant move
The source tenant is hybrid — one on-prem Active Directory synced up to Entra with Entra Connect. Now the users are moving to a different tenant, and the first thing you learn is that the sync you already have does not follow them. This is part of the Azure tenant-to-tenant migration guide.
New to cloud? CAMPUX is a free, build-first course. Start here →
People picture a tenant move as copying identities from one Entra tenant to another. When the source is hybrid, that picture is wrong in a way that bites. The on-prem AD is the master, and Entra Connect is the pump that pushes those accounts up into exactly one tenant. Point that pump somewhere new and you are not copying anything — you are deciding what the on-prem directory's future looks like against a tenant that has never seen these objects before. Get the decision and the object matching right and users barely notice. Get them wrong and you spend a weekend untangling duplicate accounts.
What Entra Connect actually does
Entra Connect is an on-premises application that synchronizes your on-prem AD into Entra ID. Microsoft's own description is plain: it is responsible for "creating users, groups, and other objects" in the cloud and "making sure identity information for your on-premises users and groups is matching the cloud," password hashes included. The users live in AD. Entra Connect projects a cloud copy of each one so the same person can sign in to Microsoft 365 and on-prem apps with one identity. Cloud Sync is the newer, lightweight, cloud-managed version of the same idea — Microsoft is steering new deployments toward it — but the mental model is identical: one directory, pumped up to the cloud.
Why the sync is tied to one tenant
Here is the constraint that shapes the whole migration. A single Entra Connect server, in Microsoft's words, "can't synchronize to more than one Microsoft Entra tenant." Syncing one AD to two tenants is a supported topology, but only by standing up a separate Entra Connect server for each tenant, and even then only one tenant is allowed to write back to AD for a given object. It exists for genuine multi-tenant setups and for a co-existence window during a move. It is not a comfortable steady state, and Microsoft is blunt about the sharp edges: you cannot verify the same custom domain in two tenants, and forest-level features like Seamless SSO and Entra hybrid join can only be wired to one tenant — configure a second and you overwrite the first.
The sync you already run points at one tenant. It does not follow your users to the new one.
The real decision: cloud-only or stand up a new sync
So in the migration you choose, deliberately, one of two futures for these users in the target tenant.
If the on-prem AD is being retired — common in an acquisition where the acquired site is folding into the buyer's cloud — the target users become cloud-only. You provision them straight in Entra, or migrate them and then cut the strings, and Entra becomes authoritative. No sync to the new tenant at all.
If on-prem AD is staying authoritative — the users keep logging into domain-joined machines and on-prem file shares — then you stand up Entra Connect or Cloud Sync against the target tenant. New sync server, new configuration, pointed at the new tenant, syncing the same (or a filtered slice of the same) AD. During the cutover you may briefly run both: the old sync still feeding the old tenant, a new one feeding the target, which is exactly the multi-tenant topology with all its caveats. It is a bridge, and you take it down deliberately once the move lands.
Entra Connect matches an on-prem object to its cloud object using the source anchor — also called the immutableId. Microsoft defines it as "an attribute immutable during the lifetime of an object" that "uniquely identifies an object as being the same object on-premises and in Microsoft Entra ID." For a single forest it is usually objectGUID, or the configurable ms-DS-ConsistencyGuid. The trap: if that value does not line up on both sides, the sync sees a stranger and makes a new account instead of linking the existing one. When you sync the same AD to a second tenant, the same source anchor can identify the same object in each tenant — that part is supported. But if an object gets recreated on-prem and picks up a fresh objectGUID, or you rebuild the sync without preserving the anchor, you get duplicates. This is why forest and tenant moves lean on ms-DS-ConsistencyGuid: its value can be carried across so the anchor survives the move.
Sequencing it against the identity cutover
Order matters as much as the choices. Two things gate everything. First, the domain: the same verified custom domain cannot live in two tenants, so it has to be removed from the source and added and verified in the target before those users can sign in with their real address. Until it is verified in the target, Entra rewrites the suffix to the onmicrosoft.com default — a visible change to how people log in. Second, the anchor: decide and stamp your source anchor before you build the target sync, because the value cannot be changed after an object has synced. If it changes after export, Entra Connect throws an error and refuses further updates on that object until you set it back. So the sane sequence is: settle the source anchor, pre-stage or hard-match the target objects to it, line up the domain move, then flip the sync — not the other way around.
The takeaway
When the source of a tenant move is hybrid, the sync is the story. Entra Connect ties one on-prem AD to one tenant, so the move forces a decision Microsoft will not make for you: do these users become cloud-only in the target, or do you build a fresh sync pointed at it. Whichever you pick, the source anchor has to match on both sides or you manufacture duplicate accounts, and the domain and the anchor both have to be sequenced ahead of the cutover. Say that out loud in a design review — "the source is hybrid, so per-tenant sync means we choose cloud-only or a new sync, and we protect the immutableId" — and you sound like someone who has actually done one.
Questions people also ask
Can Azure AD Connect sync to two tenants at the same time?
A single Entra Connect server can't sync to more than one tenant. Microsoft does support syncing one Active Directory to multiple tenants, but you deploy a separate Entra Connect server for each tenant. It works for a temporary co-existence window, but only one tenant can write back to AD for a given object, so it isn't how you run steady state — it's a bridge you take down once the migration lands.
What is the immutableId in Entra Connect?
The immutableId, also called the sourceAnchor, is an attribute that stays fixed for the life of an object and uniquely identifies it as the same object on-premises and in Entra ID. For a single forest it's usually objectGUID or ms-DS-ConsistencyGuid. Its value can't change after the object syncs — if it does, Entra Connect throws an error and stops updating that object until you set it back.
Should migrated users become cloud-only or stay synced to the new tenant?
Both are valid — it's a decision, not a default. If the on-prem AD is being retired, convert the users to cloud-only in the target and manage them in Entra. If on-prem AD stays authoritative, stand up Entra Connect or Cloud Sync against the new tenant. What you can't do is leave the old sync pointed at the old tenant and expect the users to appear in the new one.
Does a verified domain move to the new tenant automatically?
No. The same custom domain can't be verified in two tenants at once, so it doesn't move on its own. You remove it from the source tenant and add and verify it in the target before those users can sign in with their real UPN suffix. Until the domain is verified in the target, Entra replaces the suffix with the onmicrosoft.com default, which changes how people sign in.
What happens if the source anchor changes during a migration?
Entra Connect uses the source anchor to match on-prem objects to cloud objects. If the value changes — say the object is deleted and recreated, giving it a new objectGUID — the sync treats it as a brand-new person and creates a duplicate instead of updating the existing one. That's why forest and tenant moves plan the anchor carefully, often using ms-DS-ConsistencyGuid so the value can be carried across.