It’s 8 am on Monday. Someone in accounts payable opens their laptop, and your migration is about to be judged.
Over the weekend, every checkpoint went green. Mailboxes moved, sites landed, the cutover call finished early and someone bought pizza. None of that reaches accounts payable. What reaches them is whether Outlook opens, whether their inbox looks like Friday’s inbox, and whether they can remember the password they set on Thursday.
This post is about those first ninety seconds of Monday morning, and the fortnight that follows. Users judge a migration on what it asks of them. Nearly every bad Monday traces back to something nobody warned them about, far more often than to something that broke.
This is the fourth post in our seven-part series on Microsoft 365 tenant-to-tenant (T2T) migrations. New here? Start with Post 1, What a Microsoft 365 Tenant-to-tenant Migration Actually Involves, then follow the thread.
Nobody experiences a migration. They experience Monday
IT measures a migration in items moved, error rates per workload, and whether cutover finished inside the window. Those are the right numbers for running the project.
Users measure it in how much of their morning it cost. The trouble is that theirs is the measurement that travels through the business. Nobody in the lunchroom quotes the error rate. They quote the colleague who lost half a day to a phone that wouldn’t sync, and by Wednesday that story is the migration.
One of the six requirements that sit underneath every T2T is continuity: mail, calendars and collaboration keep working without visibly breaking. The word doing the work there is visibly. Underneath, everything is changing, and the aim is that users never notice where the old tenant stops and the new one starts. Every section from here is a place where they will notice, unless someone planned for it.
Your new email address is a bigger deal than IT thinks
To the project, a changed sign-in name and email address is a mapping decision made in a workshop. To the person who owns it, that address is printed on business cards, saved in every supplier’s system, typed from muscle memory into a dozen websites, and sitting in the address books of customers who won’t get the memo.
Anyone who has moved house knows the pattern. You remember to tell the bank. You forget the dentist, and the dentist is the one who rings.
Keeping the old address alive for a while softens the landing. It doesn’t make the change invisible, and users should hear about it from you before they notice it themselves.
In an acquisition there’s a second layer. The day someone’s email address ends in another company’s domain is often the day the deal becomes real to them. Months of announcements and town halls, and what finally lands is a signature block. If the acquired staff are already anxious, the migration will carry that anxiety whether you planned for it or not. Post 5, our mergers and acquisitions deep dive, will pick this up properly.
Why your migration emails look like phishing
Consider what you’re about to send: an email from an address staff don’t recognise, telling them their account is changing and asking them to sign in somewhere new. You’ve spent years, and a real security budget, teaching people to report exactly that message.
Here’s how it goes wrong. A 400-person firm sends its first “activate your new account” email from a project mailbox nobody has seen before. Three weeks earlier, the security team ran a phishing simulation with near-identical wording. A third of staff report the real thing. Security, doing precisely what it should, pulls the message from every inbox by Tuesday morning, and the project loses two days. The security team is quite pleased with the report rate. Everyone behaved correctly, and the migration is still behind.
A better-worded email wouldn’t have saved it. Migration comms need to come from someone staff recognise, through a channel they already trust, well before anything asks them to act. Security needs to know what’s going out and when.
And remember that the first migration message many users see is the request, covered in Post 3, to clean out their OneDrive and mailbox. Whatever tone that message sets, everything after it inherits.
What users actually have to do on day one
Which Monday a user gets depends on a decision most of them never hear about: how the organisation handles devices. That call usually gets made early, by people who won’t be living with it, and it means two people in the same team can have completely different mornings.
Some things land on everyone. The authenticator app on their phone needs setting up again for the new account. Chat history may come across, but not always looking the way they left it. The weekly meeting in everyone’s calendar still belongs to the old tenant, and someone has to recreate it. Executive assistants tend to discover this first, usually at 8:55 for a 9:00.
Users on their own devices get the long list of actions. Sign in to every Office app again. Re-enrol the phone so work email comes back. Wait while Outlook downloads a mailbox that may be fifteen years deep, which on a home connection can take long enough to look like data loss. No single step is particularly hard, but there are lots of them, and each one a user misses becomes a service desk call.
Users on managed devices get the opposite problem. Their laptop was set up for the old tenant, and in most cases the cleanest way into the new one is to rebuild it, which means a wipe. Afterwards there’s far less to configure. Beforehand, anything that lived only on that laptop needs to be somewhere safe.
Picture the senior engineer whose laptop is rebuilt exactly on schedule. Three years of working files lived in a desktop folder that never synced anywhere, because it was only ever meant to be temporary. The pre-migration comms told everyone to check. The engineer filed that email under “IT stuff”. The rebuild went perfectly. The files didn’t survive it.
Rebuilding laptops is also physical work. Hundreds of devices don’t all get rebuilt over one weekend, so on a managed fleet the device schedule quietly becomes the migration schedule.
Neither path is the easy one. They fail differently, and users need to know which one they’re on well before Monday.
Being in wave three
Most migrations of any size move people in batches. Whether that’s the right call is a business decision with consequences of its own, and Post 3 deals with it. This section is about what it feels like to be in a later batch.
Your team moved last week. You didn’t. Their calendars look empty when you try to book a meeting. There are two versions of the team’s channel and nobody is sure which one is live. You join your own manager’s meeting as a guest. It all works, technically, and it all feels slightly wrong for weeks.
The worst case is quieter than you’d expect. The wave plan is built from the org chart. The CFO moves with Finance in wave two. The CFO’s executive assistant reports into Corporate Services and moves in wave four. The org chart records who reports to whom; it doesn’t record who runs whose diary.
For eleven days the assistant can’t manage the CFO’s calendar properly. Invites get forwarded by hand, a board prep session is double-booked, and the assistant ends up keeping a spreadsheet copy of the diary just to stay ahead of it. Every metric on the project dashboard is green. Ask the CFO and the migration was a disaster. In fairness, it’s the only part of the migration they ever saw.
Delegated calendars, shared mailboxes a team works out of, the people who cover each other’s leave: none of it appears on the org chart, and all of it matters more to a wave plan than the reporting line does. This is exactly what discovery should surface, and it’s why Post 2Post 2 “Know Your Tenant Before You Move It” argues that migration discovery is a whole-of-business job.
Skip the training. Brief people on what’s different
Most T2T plans include a training stream, and most of it is wasted effort. After a tenant-to-tenant migration, Outlook is still Outlook and Teams is still Teams. Nobody needs to relearn how to share a file.
What people need is orientation: a short, specific account of what changes for them on Monday. Their new sign-in name. Which device path they’re on. What will look different in Teams. Who to call when something doesn’t. A one-page read in two minutes beats a forty-minute session nobody attends.
Coming from Google Workspace is a different story. Post 7 is where retraining becomes the main event.
The audience that does need a proper briefing is the service desk. They’ll hear every surprise nobody warned users about, and they need to have heard it first. A service desk learning the new sign-in format from its first caller sounds like it doesn’t know what’s going on, because it doesn’t. Don’t overlook technical champions and PAs either. Prepare them properly and they can support their peers and executives through the common issues, giving trusted help in the moment and keeping unnecessary calls off the service desk.
The two weeks after cutover are the real delivery
Post 1Post 1 “What a Microsoft 365 Tenant-to-tenant Migration Actually Involves” put the finish line a fortnight after cutover, once the service desk queue is back to its usual shape. The cutover weekend is rehearsed, staffed and watched. The fortnight after it is when the calls arrive and the organisation decides what it thinks of the project.
Builders hand over the keys on a Friday. It takes the next fortnight of living there to find out they put the light switch behind the door.
That fortnight needs people in it: visible support on the floor (or in a dedicated chat channel, for a distributed workforce) and a service desk staffed for the spike rather than a normal week. Someone should be watching sentiment as closely as the ticket count, because a quiet queue can hide a department that has simply given up reporting things. The project’s reputation is settled here, so plan this fortnight as carefully as the weekend.
Key takeaways
- Users judge a migration on what it asked of them. Most bad Mondays come from surprises rather than technical faults
- The device approach decides day one. Own-device users face a long list of small tasks; managed-device users face a rebuild, and risk losing whatever wasn’t saved elsewhere
- Wave plans built from the org chart split the working relationships that matter most, starting with executives and their assistants
- Brief the service desk before anyone else, and staff the fortnight after cutover like it’s part of the project, because it is
Next in the series: Post 5 on mergers and acquisitions, and what happens when two tenants (and two IT cultures) have to become one on someone else’s deadline.
Talk to us before anyone writes the Thursday-night email
Most organisations write their migration comms once, under pressure, in the week before cutover. Insentra has built end-user comms and orientation material for T2T migrations, shaped by watching which Mondays go well and which don’t, so your “here’s what’s changing” message isn’t being drafted at 11 pm on a Thursday.
Insentra is a partner-first consultancy, and tenant-to-tenant migration is one of the practices we’ve built deep expertise in. We know which Mondays go well, and we know why the others don’t.
We can help you shape the comms, choose the right device path, build a wave plan around the people who actually run each other’s diaries, and brief your service desk before the first caller rings. The earlier that conversation happens, the less of it you’ll have at 8 am on Monday.
Contact us while there’s still time to plan the ninety seconds that decide how your migration is remembered.
Next in the series: mergers and acquisitions, and what happens when two tenants (and two I.T. cultures) have to become one on someone else’s deadline.
