When the subscription changes tenants, the network comes along — but the wiring needs a second look
Two companies merge. One subscription is being pulled out of the old Microsoft Entra tenant and dropped into the surviving one. The good news is that the virtual networks and their gateways go with it. The bad news is everything that was holding those networks to each other, and to on-premises, was quietly tied to the tenant you are leaving.
New to cloud? CAMPUX is a free, build-first course. Start here →
This is one chapter of the larger Azure tenant-to-tenant migration guide, and it is the one people underestimate. A subscription transfer to a new tenant is supported, and the subscription keeps its ID through the move, so its resources and their resource IDs survive intact. Virtual networks, VPN gateways, and ExpressRoute circuits are all subscription-scoped resources — they live inside the subscription, not the tenant, so when the subscription changes tenants they travel with it. Nobody re-IPs a VNet on the way over. What breaks is thinner and easier to miss: the access and the authorizations that made the pieces talk.
What moves, and what quietly detaches
Hold the two layers apart in your head. The resources move: the VNet with its address space, subnets, and NSGs; the VPN gateway; the ExpressRoute circuit. The access does not. Role assignments are made against identities in a specific tenant, and when the subscription lands in the new tenant, assignments bound to the old tenant's users and groups fall away. So the morning after the transfer, the network is all still there — and the person who needs to touch a peering may have no rights to do it until access is re-granted in the new tenant. Plan the identity side as carefully as the resource side, because that is where the outage hides.
The resources survive the move. The permissions and authorizations that connected them do not.
Cross-tenant VNet peering, and what it actually allows
Peering across tenants is a real, supported thing — not a workaround. Microsoft's own constraint list says the two virtual networks in a peering can be in the same or different subscriptions, and those subscriptions "can be associated to the same or different Microsoft Entra tenant." So during a consolidation you can peer a VNet still in the old tenant to one in the new tenant and keep traffic flowing on the Microsoft backbone while you cut over, no public internet in the path.
The friction is entirely in setup. Because each side of a peering is written independently, and each side lives in a different tenant's directory, an admin has to grant the other side rights. The pattern Microsoft documents: add a user from each tenant as a guest user in the opposite tenant, and give that guest the Network Contributor role on the remote VNet. Then each side writes its half of the peering, usually by pasting the remote VNet's full resource ID rather than picking it from a list. The peering is only live when both halves show Connected — one side alone sits at Initiated and carries no traffic. And peering is not transitive: peering to a hub does not hand you the hub's other spokes, so a hub-and-spoke rebuilt across tenants still needs its explicit peerings or an appliance in the hub.
The overlapping-address-space headache
Here is the one that turns a clean cutover into a project. Peering requires non-overlapping address spaces — Microsoft states it flatly, and the reason is routing: if 10.10.0.0/16 exists on both sides, Azure cannot decide which VNet a packet is for. Two estates that grew up independently almost never have disjoint ranges. Somebody used 10.0.0.0/16 in each shop, and now they meet.
You have three honest options, in rough order of preference. First, resize a VNet's address space to remove the overlap — Azure supports resizing the address space of peered VNets with no downtime on the existing ranges, cross-tenant included, as long as you sync the peers afterward. Second, if you cannot renumber, route the two estates through a VPN gateway or a firewall doing NAT, translating the clashing ranges so each side sees the other on a clean address. Third, note that Azure Virtual Network Manager offers a peering variant that tolerates overlap — but the overlapping ranges still cannot reach each other, so it buys you connectivity everywhere except the part that collides. Renumbering is the only fix that truly removes the problem.
ExpressRoute and VPN: re-authorize, do not rebuild
The VPN gateway is inside the moving subscription, so it comes along with its public IP and its config. What you re-check is the far end — the on-premises device's expectation of the connection and any access needed to manage it in the new tenant. ExpressRoute is the more interesting case, because a circuit is often shared, not owned by the workload subscription. You do not have to move the circuit to keep using it. The circuit runs on an authorization model: the circuit owner creates an authorization key, and the owner of a VNet gateway in another subscription — or another tenant — redeems that key to connect. Authorizations span subscription, tenant, and enrollment boundaries, one authorization per connection.
That model is also the risk. The circuit owner can revoke an authorization at any time, and revoking it deletes the link connections for the subscription whose access was pulled. If the ExpressRoute circuit stays behind in the old tenant's connectivity subscription while your workload subscription leaves, your hybrid path now depends on an authorization controlled by the estate you are separating from. Confirm who owns the circuit, confirm the authorizations you rely on will stay valid or get reissued in the new arrangement, and do that before, not after, the workloads need the link. If you are still choosing between the two hybrid links in the first place, see ExpressRoute vs VPN Gateway.
Sequencing so nothing goes dark mid-migration
Order is the whole game. Reconcile addresses first — resize or renumber any overlap while both estates are calm, because you cannot peer around it later. Establish the new-tenant access next: guest users and Network Contributor on both sides, and re-grant the role assignments the transfer will drop, so the right hands can work the moment the subscription lands. Then build the new cross-tenant peerings and confirm both halves read Connected before you tear down the old ones — you want the new path proven while the old path still carries traffic. For ExpressRoute, verify authorizations end to end and keep the existing connections until the replacement is live. Move the subscription, re-check every connection object, and only then retire what the old tenant was holding up. Done in that order, nobody on either side notices the ground moved under them.
The takeaway
A tenant consolidation does not uproot your network — the VNets, gateways, and circuits ride along inside the subscription with their IDs intact. What you migrate is the connective tissue: access that was bound to the old tenant, cross-tenant peerings that need guest users and Network Contributor on both ends, ExpressRoute authorizations that can be revoked out from under you, and any overlapping address ranges that make peering impossible until you renumber. Fix the addresses, re-grant the access, prove the new paths before dropping the old ones, and hybrid connectivity survives the move without a dark window.
Questions people also ask
Can you peer VNets across two different Azure tenants?
Yes. Two subscriptions in a peering can sit in the same or different Microsoft Entra tenants. The catch is access: an admin in each tenant has to add a user from the other tenant as a guest and grant that user Network Contributor on the remote VNet, so each side can write its half of the peering. Both halves must reach Connected.
Does VNet peering support overlapping IP address spaces?
No. Standard VNet peering requires non-overlapping address spaces, because overlapping ranges make routing ambiguous. If the two estates collide, you either resize a VNet's address space to remove the overlap, which peering supports without downtime after a sync, or you route through a VPN gateway or firewall doing NAT to translate the clashing ranges.
What happens to a VPN gateway or ExpressRoute circuit when a subscription moves to a new tenant?
They travel with the subscription. Virtual networks, VPN gateways, and ExpressRoute circuits are subscription-scoped resources, and the subscription keeps its ID through a tenant transfer, so the resources and their IDs survive. What does not survive is access: role assignments tied to the old tenant's identities fall away and have to be re-established in the new tenant.
Do you have to move the ExpressRoute circuit itself when consolidating tenants?
Not necessarily. A circuit can be shared across subscriptions and tenants through authorizations. The circuit owner creates an authorization key, and the owner of a VNet gateway in another subscription or tenant redeems it to connect. One authorization covers one connection, and the circuit owner can revoke it at any time, which drops that connection.
Is VNet peering transitive across a hub?
No. Peering is not transitive. If VNet A peers with hub B, and hub B peers with VNet C, A and C still cannot talk through B on peering alone. You either add a direct peering between A and C or route them through a network virtual appliance or gateway in the hub. This matters when you rebuild a hub-and-spoke across tenants.