And who really sets the deadline
The project doesn’t start in IT It starts in a room you weren’t in.
A board approves an acquisition. A lawyer signs a carve-out. Somebody finally loses patience with running four tenants for one company. Weeks later, it arrives on your desk phrased as a question that sounds almost casual, “We’re moving everyone into a new tenant, can that be done by March?”
The honest answer is usually yes. Which is precisely what makes the question so dangerous.
This is the first post in a seven-part series on Microsoft 365 T2T (tenant-to-tenant) migrations. Start here, then follow the thread.
What a tenant-to-tenant migration actually is
wo Microsoft 365 tenants. One set of humans. Everything those humans use has to come out of the first tenant and turn up in the second without them losing the thread of their working lives.
Easy to say. The difficulty is that a tenant isn’t a database you copy. It’s three boundaries stacked on top of each other: an identity boundary (who your people are), a security boundary (what they can reach), and a compliance boundary (what you can prove about what they did). Moving data is the visible part of the job. Rebuilding those three boundaries somewhere else, correctly, while people keep working, is the actual job.
It’s the difference between moving your possessions and moving your address. The boxes are the easy bit. It’s everything that knew where to find you that causes the trouble.
The 3 Triggers Behind a Tenant Migration
Nobody does this for fun. There are three reasons you’re reading this, and each bends the project in a different direction.
- A merger or acquisition wants speed, and it wants the two organisations talking to each other before they are properly one organisation. Coexistence stops being a nice-to-have and becomes a requirement and coexistence is where the budget quietly goes. More on that in the M&A (Mergers & Acquisitions) post.
- A divestiture inverts everything. You aren’t moving a business you’re extracting one, and what your counterparty cares about most is what you leave behind. Provable separation is the deliverable. It earns its own post.
- Tenant consolidation is the only trigger where you set your own deadline. Which is exactly why it’s been on the roadmap for three years, losing to whatever was on fire that quarter.
And the one that isn’t a trigger
Rebrands come up frequently in this conversation and mostly don’t belong in it. A new company name and a new email domain are an in-tenant change. You don’t build a second tenant and move house because the logo changed, and any conversation drifting that way deserves a firm question about why.
Where a rebrand genuinely appears in a migration, it’s riding along with one of the three above. The acquired business gets a new name. The divested one needs an identity of its own. The rebrand doesn’t create the project; it makes the identity decisions inside it louder.
The workloads everyone names, and the ones they forget
Ask anyone what’s in scope and you’ll get the same four: Exchange, SharePoint, OneDrive, Teams.
Fine, but they aren’t equivalent problems. Exchange is large and well understood. SharePoint is where permissions models go to become somebody’s ongoing crisis. OneDrive looks simple until you ask who owns the OneDrive of a person who left in 2022. Teams is a puzzle box: chat, files, channels, apps and calls all live somewhere different underneath, and users think of them as one thing.
Then there’s the long tail. This is the part that sets your date, and it’s never in the original estimate:
- Shared and resource mailboxes with no clear owner
- Mail-enabled security groups holding together processes nobody documented
- Planner plans, Loop components, Power Platform dashboards, apps and flows quietly running the business
- App registrations and service principals authenticating things you forgot you bought
- Third-party SaaS that trusts a tenant ID nobody wrote down
- Bookings pages, room lists and calendar delegations
- The finance system that only accepts mail from one specific SMTP domain, and has done since 2016
None of that is exotic. All of it is real, and every item is a small conversation with a human who may no longer work there.
Every one of those examples come from a real discovery.
An HR system with hooks all through the tenant, held together by Power Automate flows that nobody had built, owned, or documented. A site that had simply been overlooked, quietly holding content the business would have missed the moment it vanished. Orphaned, unlicensed accounts still hanging onto mail aliases that made domain-name removal problematic (to say the least).
And the particularly good one: 80% of the accounts in the tenant were still flagged as a synced objects from on-premises Active Directory, but directory sync had been decommissioned 18 months earlier.
Nobody in the building knew, because nothing had visibly broken.
That’s a fortnight, minimum, before anyone moves a byte. It is also barely scratching the surface.
What “done” actually looks like
Here’s a definition of success I’d like to retire. “The cutover weekend went fine.”
The cutover weekend nearly always goes fine. It’s rehearsed, it’s staffed, and it’s the part everyone is watching. Done is a fortnight later, when mail is flowing, everything is stable, the auditors are satisfied, and the service desk queue has come back down to the shape it was before.
Which means “done” has to be agreed before anyone touches anything. Six requirements sit underneath every T2T, and the business, not IT, signs each one:
- Continuity: means mail, calendars and collaboration don’t visibly break
- Fidelity: means data, metadata, permissions and versions arrive intact, or the deviations are consciously accepted and documented
- Compliance: means retention and legal holds survive the move and you can prove it
- Identity: means people keep a coherent story about who they are, or the change is deliberately managed
- Timeline: the deadline is almost always imposed from outside
- Budget realism: Discovery will change the scope. That’s why why contingency isn’t optional
Those six recur through the whole series. The audit post covers what breaks fidelity. The data post covers what fidelity even means for you. The people post covers what continuity feels like from a laptop at 8 am on a Monday.
How long this really takes
Rough numbers, honestly given:
- Discovery, requirements and workshops: Anywhere from 3 to 6 weeks. Never the week the sponsor imagined
- A mid-sized tenant or Google Workspace as the source (roughly 500 to 2,000 users, no unusual compliance burden): 3 to 6 months end to end.
- Enterprise, or anything involving a divestiture or heavy regulation: 6 to 12 months, occasionally longer.
- The data movement itself: a small fraction of any of the above.
Now the part that matters. None of those numbers will set your deadline. Your deadline comes from a Transition Services Agreement, a share purchase agreement, a licence renewal or a press release that has already gone out. The plan bends to the date, not the reverse.
So, something else has to flex, and there are only three candidates: scope, cost, and how much junk you agree to carry across. Choose early, or the project chooses for you.
The business project wearing an IT costume
Every genuinely hard question in a tenant migration is a business question in technical clothing.
Which tenant wins. Whose email address changes and whose doesn’t. What data are you contractually obliged to leave behind. What you’re willing to have degraded for a day, and for whom. What does “acceptable” means to the executive assistant who runs four calendars.
IT can’t answer any of those questions, and it’s usually the last to be asked.
Migrations don’t fail in Exchange.
They fail when a whole-of-business project is handed to two people in IT and everyone else goes back to work.
On one migration, a business was being separated from one group and moved into another. Before anything could move, someone had to answer a long list of questions about the environment.
Which users were which. Who owned what. What went, and what stayed.
Hundreds of users. Well over a hundred Teams. More OneDrives than there were people, which tells you something on its own.
The questions landed with the IT manager, who had one colleague and no realistic path to answering them.
Not through any failing of theirs. They knew the systems cold.
What they didn’t know, and had never had reason to know, was which of those hundreds of people sat in which department, which of those Teams still mattered to anyone, or who to ask about the ones that didn’t. That knowledge lived out in the business, with the people who did the work, and nobody had been asked to go and get it.
So the project stopped.
Nothing was technically wrong.
It simply sat there, waiting on answers that IT was never in a position to give.
Key takeaways
- A tenant is an identity, security and compliance boundary. Copying data is the smallest part of rebuilding one
- The four headline workloads are the part you can scope. The long tail is the part that moves your date
- “Done” is weeks after cutover, not days
- Your deadline comes from a contract, not a capacity calculation. Decide what flexes before it decides for you
The series from here
Know your environment: Why you can’t price a migration for a tenant you don’t understand.
Know your data: Lift-and-shift or spring clean, big-bang or staged migration and why that’s a business decision worth discussing.
Know your people: The migration is easy. The humans are hard.
Mergers and acquisitions: When two tenants become one and the TSA clock is already running.
Divestitures: Separations, not migrations. Untangling is the hard part.
Coming from Google?: Why Workspace to Microsoft 365 breaks most of the assumptions above.
Talk to us before the deadline is set
Insentra is a partner-first consultancy. We don’t compete with the people we work alongside, and tenant-to-tenant migration is one of the practices we’ve built deep expertise in.
We’ve run the discovery that uncovered the forgotten integration. We’ve sat in the room where nobody wanted to own the domain decision.
We’re often bought at one of two moments: when the deadline is set, or when the project is already under pressure.
The earlier conversation is usually the more valuable one.
Contact us while there’s still room to shape the scope, timeline and approach.
