Or, why “just remove the domain from the source tenant” is never as simple as it sounds
Tenant-to-tenant migrations follow a predictable rhythm. Migrate the mailboxes. Migrate the data. Flip the domain. Celebrate.
That middle bit “flip the domain” is where things get interesting. Because before you can add that shiny production domain to your target tenant, you have to remove it from the source tenant first. Microsoft 365 domains are strictly monogamous; they can only belong to one tenant at a time.
And source tenants? They don’t like letting go.
What follows is a public service announcement for anyone approaching the domain cutover phase of a migration. That domain removal you’ve scheduled for an hour? Block out a day. Maybe two.
The Moment of Truth
The migration has gone smoothly. Users are moved. Data is synced. You’re in the cutover window, ready to flip the domain so mail starts flowing to the new tenant.
Step one: remove the domain from the source tenant.
You navigate to the Microsoft 365 admin center, find the domain, click remove, and
“This domain can’t be removed because it’s associated with user accounts or groups.”
Your cutover window just got a lot more interesting.
Why This Happens (Every Single Time)
Here’s the thing: you migrated the mailboxes. But the source tenant is full of other objects that also use email addresses. Objects that weren’t in your migration scope. Objects that have been quietly accumulating since the tenant was created, and every single one of them has an opinion about whether that domain is leaving.
The domain is essentially a cork in a bottle full of address references. You can’t pull the cork until you’ve emptied the bottle. And the bottle is deeper than you think.
The Rogues’ Gallery of Domain Blockers
When you start hunting for what’s holding the domain hostage, you’ll encounter the usual suspects and then you’ll encounter the unusual ones.
Distribution lists: The classics. Half of them are for projects that ended years ago. The other half have owners who’ve left the company. All of them have an email address on your domain and no intention of giving it up.
Microsoft 365 Groups: Every Teams team creates one. Every Planner plan creates one. Some of them were abandoned within a week of creation. They’re all still there, and they all have addresses.
Shared mailboxes: The finance team’s shared mailbox. The old support queue. The “temporary” mailbox someone created for a project in 2021 that’s still receiving mail. None of these migrated with your users.
Resource mailboxes: Conference rooms. Equipment. The booking calendar for a projector that was thrown out three office moves ago. All mail-enabled. All blocking your domain.
Mail contacts: External contacts someone created manually. Maybe for a vendor. Maybe for a partner. Maybe for reasons that made sense to someone once. Each one potentially using your domain.
Mail-enabled security groups: Yes, these exist. No, you probably didn’t know you had any. Surprise.
Soft-deleted users: This one catches everyone. When users are deleted in Entra ID, they sit in a recycle bin for 30 days. During that time, they’re still “using” the domain. Your migrated users might have been deleted from the source tenant, but if they’re still in the recycle bin, they’re still blocking the domain.
Soft-deleted groups: Same story. Deleted Microsoft 365 Groups linger for 30 days, holding their addresses the whole time.
SIP addresses: Teams phone system configurations. Users might have SIP addresses on the domain even after their primary SMTP has been changed. It’s a different attribute, a different place to check, and an easy one to miss.
The Discovery Gap
If you’re wondering why your pre-migration discovery didn’t catch this, the answer is simple: discovery focuses on what’s moving.
You inventoried users and mailboxes. You scoped data volumes. You documented licenses. All of that was about the migration getting things into the target tenant.
But domain removal is about what’s staying behind. The abandoned groups, the orphaned shared mailboxes, the soft-deleted accounts, none of these were in scope for migration, so none of them appeared in your migration discovery.
The objects blocking your domain are, almost by definition, the objects you weren’t planning to deal with.
The Systematic Approach
The good news: this is a solvable problem. The bad news: it requires methodical work, and it’s best done before your cutover window, not during it.
Step 1: Inventory everything using the domain
Run queries against Exchange Online for every object type that can hold an email address:
- User mailboxes (including any not yet migrated or deleted)
- Shared mailboxes
- Distribution groups
- Microsoft 365 Groups (including Teams-connected groups)
- Mail contacts
- Mail users
- Resource mailboxes (rooms and equipment)
Export the lists. This is your cleanup manifest.
Step 2: Purge the recycle bins
Check Entra ID’s deleted users. Check deleted Microsoft 365 Groups. If these objects need to stay deleted, permanently remove them. If they need to be recovered, recover them and then deal with them properly. The recycle bin is not a holding pattern—it’s a domain blocker in disguise.
Step 3: Reassign to the fallback domain
The source tenant’s .onmicrosoft.com domain is your escape hatch. For every object that’s staying behind shared mailboxes, groups, contacts, resources switch their addresses to the .onmicrosoft.com domain. This releases the production domain without deleting the objects.
Step 4: Handle the edge cases
Check Teams admin for SIP address assignments. Check for mail-enabled security groups (these hide in Exchange, not Entra ID). Check for any third-party integrations that might have created mail-enabled objects.
Step 5: Test the removal before cutover
Once you think you’re clean, try removing the domain. Do this before your cutover window, not during it. If it fails, Microsoft will tell you something is still attached. Find it, fix it, repeat until the domain releases.
Step 6: Then and only then proceed with cutover
With the domain confirmed as removable, you can confidently schedule your cutover knowing the domain will actually release when you need it to.
The Time Factor
Here’s what nobody wants to hear: source tenant cleanup can take longer than the migration itself.
Moving mailboxes with modern migration tools is fast. Hunting down every orphaned distribution list, getting confirmation that it can be deleted, finding out who owns the shared mailbox that “definitely still needs to exist,” and systematically clearing address references from dozens or hundreds of objects?
That takes time. Often weeks. Sometimes more, depending on how much archaeology is required and how many stakeholders need to approve deletions.
Start early. The moment you know a migration is happening, start the source tenant inventory. Every blocker you identify and resolve before cutover is a blocker that won’t be staring you down at 11 PM on Saturday night.
Lessons From the Trenches
Lesson 1: Your migration scope is not your domain cleanup scope.
What you’re migrating and what’s blocking the domain are two different sets of objects. Plan for both.
Lesson 2: Soft deletes aren’t deletes.
Recycle bins are holding cells, not exits. Objects in recycle bins still block domain removal. Permanently delete or restore, don’t ignore.
Lesson 3: The .onmicrosoft.com domain is your best friend.
Every object that can’t be deleted can be switched to the fallback domain instead. It’s ugly, but it works.
Lesson 4: Test the domain removal before cutover.
Never assume the domain will release. Confirm it. If you can’t remove it during testing, you won’t be able to remove it during cutover either.
Lesson 5: Distribution lists are where domain removals go to die.
They accumulate endlessly, they’re rarely cleaned up, and they’re always blocking something. Start there.
The Happy Ending
With systematic preparation and early cleanup, the domain will release on schedule. You’ll remove it from the source tenant, add it to the target, flip DNS, and complete the migration without drama.
And then, a few months later, someone will mention that there’s another migration coming up.
“We’ve already done one of these,” they’ll say. “The domain part is easy now, right?”
Right.
Got a domain that won’t let go? We’ve spent more time than we’d like to admit excavating source tenants. If you’d rather not learn these lessons the hard way, contact us and we are happy to help.
