Microsoft 365 Migration: What to Expect and What Can Go Wrong

A Microsoft 365 migration moves your mail, files, and identity into the cloud through a phased cutover, not a single flip of a switch. Email keeps flowing to both the old and new systems during DNS propagation, and the full switch happens only once we’ve confirmed everything landed correctly.

Ask an IT provider for a hard date and you’ll usually get one of two answers. A confident number that turns out to be wrong, or an honest “it depends.” We give the second answer, and we’ve learned not to apologize for it. It’s the honest one.

The Real Timeline: Why We Won’t Give You a Day Count

Microsoft’s own documentation describes moving an email organization to Microsoft 365 as something that happens “over a few days,” not a fixed number. That’s not corporate hedging. Not even close. Mailbox size, item count, network throughput, and how many other migrations Microsoft is processing on their backend at that exact moment all move the number, and none of those variables are things we control from our side.

Microsoft also intentionally throttles migration speed to protect the performance of its own service for every other tenant sharing that infrastructure. A migration that looks like it should finish over a weekend based on raw bandwidth math can stretch into the following week for reasons that have nothing to do with anything we did wrong. Anyone who promises you Friday at 5pm before they’ve even started the mailbox count is guessing. Confidently.

What we can commit to is the sequence, and the fact that your team keeps working through all of it. That part’s non-negotiable. Every migration through VJNetworks’ Cloud & Microsoft 365 services follows the same disciplined order regardless of how long the number ends up being.

What Happens to Your Email During Cutover

Here’s the part that surprises most owners. Nothing goes dark. Nothing at all. According to Microsoft’s own migration documentation, email sent to users whose mailboxes have already been migrated keeps routing to the old, on-premises mailbox right up until the MX record actually changes. Two mail systems exist in parallel, quietly, for as long as the migration takes. Both working.

The MX record is what tells the rest of the internet where your email lives. We don’t touch it early. We don’t touch it until every mailbox has been verified migrated and every user account has a license attached. Only then does the switch happen, and even that isn’t instant. Microsoft recommends lowering the DNS TTL to around five minutes before cutover specifically so the propagation itself moves fast once we flip it, then raising it back afterward. Most mail systems worldwide pick up the change within a few hours. A small number of stragglers can take up to 72 hours to catch on. We wait it out. That’s why we don’t delete the old migration batch until that window has passed.

Nobody’s inbox goes empty. Nobody misses an email because a server somewhere hasn’t caught up yet. Not one message. That’s the entire point of doing it this way instead of yanking the MX record on day one and hoping.

What Moves, and Where People Get Tripped Up

Email and calendar data, meaning mailbox contents, contacts, and distribution groups, move over cleanly in most cases. Mail-enabled security groups are the exception. They can fail to recreate properly, silently breaking a distribution list nobody notices for weeks. Files and folders move from shared drives into SharePoint or OneDrive. A messy file structure gets migrated exactly as messy as it started, because cloud storage doesn’t clean up ten years of “Copy of Copy of Invoice_final_v2” on its own. Teams and permissions bring chat history and channels along fine, but permissions that made sense on an old file server rarely map cleanly to SharePoint’s sharing model. Somebody always ends up with access they shouldn’t have, or locked out of something they need. Then there’s whatever’s integrated with the mail or file system. The one piece of accounting or scheduling software nobody thought to check, right up until it stops talking to the mail server.

Every one of those four categories has the same underlying cause. Same root, every time. Something that worked because of years of small workarounds gets moved without carrying the workaround along with it.

Before the Migration Even Starts

The work that actually prevents problems happens before a single mailbox moves. Domain ownership gets verified through a TXT record with Microsoft, licenses get purchased and assigned so migrated data has somewhere to land, and full backups of the existing mail and file environment get taken regardless of how confident anyone is in the process. No exceptions.

• Every mailbox, shared mailbox, and distribution list gets counted and sized before migration starts, not discovered mid-migration
• Licenses are assigned and active before the first mailbox moves, because an unlicensed mailbox doesn’t receive migrated mail
• Users hear about the change at least a couple of weeks out, then again the week of, then get a same-day heads-up. Silence is what turns a routine migration into a help desk avalanche
• The current file structure gets a hard look before it moves, not after. Nobody wants a cloud version of the same mess

Skip the inventory step and you find out what you missed the hard way. Always the hard way. Usually from a user asking where their calendar invites went.

Where Migrations Fall Apart

Most failed migrations aren’t technical failures. Not really. They’re planning failures that only look technical once something breaks. Leaving security configuration for “after the move” is the biggest one we see. MFA, admin role review, and mobile device policies all need to exist before go-live. Before, not after. Not as a follow-up project three months later when nobody remembers to circle back.

The second most common failure is treating training as optional. A migration can be technically flawless on the backend, every mailbox intact and every permission correct, and still feel like a disaster if nobody explained where the search bar moved or why Outlook looks different Monday morning. Productivity dips during any transition. It dips longer and deeper when the only communication was a calendar invite for the cutover window itself.

What a Clean Cutover Actually Looks Like

Assessment first. Always first. We count everything, flag the workarounds, and get licenses in place before touching a single mailbox. Then migration runs in the background while your team keeps working normally, old system still live, new system quietly filling up behind the scenes, invisible to anyone who isn’t looking for it. We verify every mailbox, every shared drive, every permission before anything user-facing changes.

Only after that verification does the DNS cutover happen, TTL already lowered ahead of time, both systems still able to receive mail during the propagation window, exactly as Microsoft’s own cutover process describes it. We watch that window closely rather than walking away the moment the record updates. Once routing is confirmed clean, and only then, the old migration batch gets deleted. Not before. The on-premises system gets retired on its own schedule, not rushed to hit an arbitrary date somebody picked before the mailbox count was even known.

Twenty years of doing this teaches you that the migrations nobody remembers are the successful ones. Boring, in the best way. The ones people remember are the ones done fast and wrong. If you’re still comparing providers before committing to one, our guide on evaluating an MSP before you sign anything covers what to ask about a migration plan specifically.

Getting a Real Number for Your Migration

Every range in this piece stays a range for a reason. Yours doesn’t have to. A free IT assessment counts your actual mailboxes, sizes your actual data, and flags the workarounds your current setup is already carrying, the same information that turns “over a few days” into a real sequence with a real starting point. That’s the conversation that replaces guessing with a plan, and it’s the same one we’d run before touching a single mailbox anyway.

Questions We Get Before Every Cutover

The timeline is never a single number, and anyone who gives you one before counting your mailboxes is skipping a step. What we can promise is that your team keeps working while it happens, and the switch only flips once we’ve confirmed it’s clean. A free assessment is where that mailbox count actually starts, along with everything else that determines your real number, through VJNetworks’ managed IT services.