Microsoft 365 Tenant-to-Tenant Migration - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Most companies think of Microsoft three hundred sixty five. Migration is just copying files from one account to another, and that assumption is exactly what sinks the project. When a merger closes or a division gets sold, two separate Microsoft accounts have to become one, and nothing carries over on its own. The mailboxes and files usually make the trip, but the teams chats, the shared planners, and the app connections are where the wheels come off. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're explaining tenant to tenant migration in plain words. So by the end, you'll understand what moves, what breaks, and why. The domain is always the last thing to flip.

0:42 What a tenant really is. Before we go anywhere near the moving trucks, let's agree on what a tenant actually is. The word sounds heavier than it needs to. A tenant is the private space. Your company gets inside Microsoft's cloud. Think of it as one big account that belongs to your organization and to nobody else. And everything your people use lives inside it. their mailboxes, their OneDrive files, their shared SharePoint sites, and every team they work in all sit within that single boundary. If you've never heard the word before, you aren't behind most people who use Microsoft three. Sixty five every day. Have no idea a tenant exists the same way most people drive a car without ever thinking about how the fuel gets to the engine, its plumbing, and it only becomes visible when something has to change. When you sign in with your work email, you're stepping into that tenant.

1:22 Your login, your password, your files, and your chats all belong to it, which is why losing access to the tenant feels like losing access to your entire work life. The word comes from real estate. When you rent an office, you don't own the building. You rent a suite inside it. A Microsoft tenant works the same way because Microsoft owns the buildings, which are the data centers, and your company rents one secure suite inside them. The part that matters for everything that follows is simple. The tenant is the box, not the tools. Outlook teams, SharePoint and OneDrive are just the rooms inside the box and your email address, your files and your chat history all sit within one boundary that Microsoft treats as a single customer most days, that boundary is a good thing. It keeps your data separated from every other company on the planet, and it makes security and billing simpler because there's one place to manage it all.

2:07 But that boundary also means two companies never share anything by default. If your neighbor's company and your company both run on Microsoft three hundred sixty five. You can't reach into their tenant and they can't reach into yours. The boxes stay sealed until someone decides to move. So when two organizations need to become one or one, organization needs to split into two. You can't wave a wand and merge the boxes. Someone has to carry everything from one box to the other, piece by piece. And that is the whole idea behind tenant to tenant migration. Why companies leave one tenant for another. A tenant to tenant migration almost never starts because someone in it woke up bored. It starts with a business decision that lands on its desk with a deadline already attached. The most common trigger is a merger, which is when one company buys another company A signs the deal, company B becomes part of it, and suddenly you have two separate Microsoft tenants that both need to act like one.

2:55 People on both sides need to email each other, share files, and sit in the same teams meetings and separate tenants. Make every one of those things awkward. The mirror image catches people off guard, too. A divestiture happens when a company sells off one of its business units, and a spin off is a close cousin, where a unit gets split into its own company. In both cases, a group of people who used to share a tenant with the parent now needs to leave and stand on their own, which means you're splitting one box into two instead of merging two into one. Rebranding works the same way, just without the drama of a deal. Maybe two brands become one and need a single shared tenant. Or maybe a business inherited a messy old tenant from a past acquisition and finally wants to start fresh. There's no crisis, just a decision that the current setup doesn't fit anymore. Notice what all of these have in common.

3:36 The technology is the last thing anyone thinks about. The lawyers and the executives decide the shape of the deal, and it gets handed the job of making it real, usually with a hard date attached. On day one, after a deal, people expect to work together the way they always have. That's the real tension here. The business moves at the speed of a signature, and the migration has to catch up without breaking anyone's Monday morning. What actually moves? Now for the question everyone actually cares about, which is whether your stuff comes with you. The short answer is that the big everyday things do move, your mailbox comes across, and so do your calendar and your contacts. Your personal files travel with you through OneDrive, and your team's shared documents come along through SharePoint. Those three are the well-trodden part of the job, and they're the reason the migration is possible at all.

4:17 There's a strict order to how it happens and the order matters. Identity goes first, which means the user accounts have to exist in the new tenant before anything can be attached to them. Picture a new office building because before you move anyone's desk in, you have to hand out the keys and put names on the doors. Once the accounts exist, the content follows. Mail usually goes first, then files, and it rarely happens all in one night. Most real projects move people in waves, a department here and a region there. So the business keeps running while the migration grinds through the list. A wave might be one office, one department, or one group of mailboxes that all share a deadline. Microsoft has built its own tools for parts of this, and they've improved over the years. There's a native way to move mailboxes from one tenant to another, and Microsoft has been adding tools that move a single person's mailbox, their OneDrive, and their teams data together for a straightforward move that covers a lot of ground.

5:06 But the brochures gloss over something important. Microsoft's own tools cover parts of the job, not all of it, and most real projects still bring in third party migration tools to handle the rest. Those tools exist for a reason, and that reason is that the workloads, which are easy to describe, like mail and files, are genuinely the easy ones. The word you'll hear for the actual switch is cutover. A cutover is simply the moment a person leaves the old tenant and starts working in the new one. Everything before it is preparation, and everything after it is cleanup. So the good news is real. Your email and your files are going to make the trip, but that's only half the story because a tenant holds far more than mailboxes and folders, and the parts beyond mailboxes and folders are exactly where this gets hard.

5:46 The teams problem teams is where a migration stops feeling like a copy and starts feeling like a rebuild. The reason is that a team isn't one thing. It's a group chat, a set of channels, a shared file area, and a list of people all stitched together. When you move a mailbox, you move one object. When you move a team, you're moving several objects that all point at each other, and those connections don't travel nearly as neatly. Chat history is the classic trap. You're one on one, and group chats are tied to the people and the tenant they live in, and they don't always come across cleanly in a move. A message that felt permanent can turn out to be one of the things that gets left behind. Permissions are the next quiet problem in the old tenant. Someone set up who could see which files and which channels, and none of that copies itself. On the other side, somebody has to rebuild.

6:26 Who has access to what? Or people open a familiar sight and find themselves locked out. There's a whole family of Microsoft three hundred sixty five apps that hang off teams and SharePoint planner, boards, forms, loop, whiteboard, and to do are all known to break or need manual handling in a tenant to tenant move. They break for a structural reason, which is that they were built to live inside one tenant, and you're asking them to live inside a different one. Automation catches almost everyone and it catches them late. Power automate flows and power apps are little programs people built to do work automatically, and they're tied to the old tenant. Even when you can move them, the connections they rely on don't come along. So somebody has to sign back in and reconnect them on the new side. If nobody remembers those flows exist, they just stop quietly on the day of the move.

7:06 The reframe that matters is that the data usually isn't lost, and what breaks instead is the wiring around it. Teams, permissions, planners, and automations are all wiring, and wiring is the one thing a tenant boundary was built to keep. Separate the domain move. Every message we've talked about needs an address to live at, and that address is the domain. This is the single most important moving part in the whole project. So let's slow down and get it right. A custom domain is the part after the at sign in everyone's email address. If your address is you at your company com, then your company dot com is your domain and it's the piece the outside world uses to find you. When a customer types your company name into an email, your domain is what routes the message to your inbox. Domains are tricky for one simple reason a domain can only live in one tenant at a time because it works like a single front door and you can't hang the same front door on two different houses.

7:53 So to move a domain, you have to release it from the old tenant first, and only then can you add it to the new one. The order isn't a suggestion if you try to add it before the old tenant lets go. The new tenant rejects it because as far as Microsoft is concerned, that name is already taken. This is also the moment the outside world notices the move until the domain flips. Everyone still emails your old address and the old tenant still answers the instant you release the domain and re-add it on the new side, your public email address points at a different building. Any mail sent during that gap has to be caught and rerouted, or it's simply lost. That's why people treat the domain move like surgery. You plan the exact order, you pick a quiet window and you have a way to catch the mail that arrives while the patient is on the table. In a lot of projects, the domain is treated as the finish line because the day it flips is the day the old tenant stops being anyone's daily reality.

8:41 Running both tenants at once. One fact about these projects surprises almost everyone for a while. The company runs both tenants at the same time on purpose. The idea is called coexistence, and it exists because you can't move thousands of people in one night without breaking the business. So instead of a single dramatic switch, you move people in batches. And during those batches, the old tenant and the new tenant both stay live. The two tenants get linked. So the basics still work across the gap. If someone who has already moved sends an email to someone who hasn't, it has to arrive. If two people need to chat and one of them is on each side, that has to work too. Coexistence is the scaffolding that holds the business up while the building is being rebuilt underneath it. Mail is the clearest example. While the move is in progress, mail sent to a person's old address gets caught and passed along to their new one, so nothing drops on the floor during the transition.

9:27 Addresses get rewritten along the way, which means a message can leave one tenant land in the other and still look like it came from the right person. The trade off is real. Coexistence keeps everyone working, but it also means you're running two of everything for a while. Two sets of rules, two places to check and two systems to keep in sync. It's more work, not less. And it's the price of not freezing the whole company. A good way to picture it is moving house. While keeping the old place furnished for a few weeks. Nobody has to sleep on the floor, but you're paying rent on two addresses until the last box is out the door. Cut over. Weekend coexistence can't last forever. And the day it ends has a name. The cut over is the moment the company stops using the old tenant and commits to the new one. Cutover usually lands on a weekend or on the quietest window a business has, and the reason is simple.

10:10 This is the point where things can go dark for a few hours and you want as few people affected as possible. A Saturday night is a lot cheaper than a Tuesday afternoon. By the time cutover arrives, most of the data is already across. So this window is about the last mile and the switch rather than the whole journey. The order of operations is the same almost every time, and it's worth seeing once the team freezes changes, which means people stop editing files and sending from the old box so nothing shifts underneath the move. The last of the mail and files get moved across the domain, flips to the new tenant, and then everyone checks that mail is flowing in both directions before anyone exhales. That freeze is the part users actually notice. For a short window, people are told to hold off on big edits and to expect a little turbulence. And if they follow that instruction, the move lands cleanly.

10:52 The tension lives in the timing. If the domain flip and the mail flow don't line up, messages bounce, and inside a company, a bouncing email is the loudest alarm there is. Everyone notices at once and the migration team's phone lights up. So cutover is the point of no return, and it's designed to be short and sharp rather than long and gentle. You do the risky work in the dark. You confirm everything flows and you come out the other side with one tenant instead of two. What usually goes wrong? Even with a careful plan, certain things are famous for going wrong in a tenant to tenant migration and knowing them ahead of time is half the battle. Start with the small invisible things because that's where most failures live. Shared links are a good example. A link to a file that people clicked every day in the old tenant doesn't automatically point anywhere useful in the new one.

11:33 Access that felt permanent was really just a setting inside a tenant that no longer exists. Chat and app data is the next soft spot. Teams. Chat history and the content inside. Tools like Planner and Forms can be partially left behind if nobody planned for them. The data isn't necessarily destroyed, but it can become hard to find which for a busy team feels the same as gone. Automations are the quietest failure of all a power automate flow that file documents or sent reminders every morning simply stops because its connections died with the old tenant. Nobody notices for weeks until someone asks why a process that used to run itself no longer runs at all. Mail gaps are the most visible risk. If the domain switch and the mail routing aren't lined up perfectly. Messages bounced during the switch, and a bounced email to a customer is the kind of mistake people remember for a long time.

12:17 There's also a limit worth being honest about. Even Microsoft's own environment moves only support certain types of environments, which means some things have to be rebuilt by hand rather than carried across. No tool erases that work, and none of these failures are exotic. They are the ordinary gaps between what a plan covers and what an ordinary Tuesday actually demands. This is why a careful migration runs a small test group first. You move a handful of people, you watch what breaks, and you fix the pattern before you repeat it across thousands of mailboxes. And then there's the people problem, which is the one it can't patch. Even a flawless technical move disrupts habits. Someone who can't find a familiar file on Monday morning blames the migration, not the file, and that feeling spreads faster than any status update. The projects that go well are rarely the ones that move the most data.

13:00 They're the ones that plan for the boring, invisible things nobody wanted to think about. The recap. So let's pull the whole thing together in a few sentences. A tenant is your company's own box inside Microsoft's cloud, sealed off from everyone else. A business event like a merger, a sale, or a rebrand forces people to move from one box to another. Identity goes first, then mail and files. Then the custom domain flips last, and along the way, the two tenants run side by side so the business never stops. The email was the easy part all along, and the wiring around it is what makes these projects hard. That wiring is the teams chats, the permissions, the planners, and the automations that nobody remembers until they break. So I'll leave you with one question. If your own company had to move tenants next quarter, which part would you trust your team to get right and which part would keep you up at night?