Every MSP says Microsoft 365 migration is “seamless.” Here’s what actually happens.
We’ve run a lot of these migrations across Minnesota businesses — manufacturing firms in the Twin Cities, healthcare clinics in the suburbs, professional services firms all over the state. And we’ve seen the same pattern play out when another provider sold a client on a “weekend migration”: Monday morning rolls around, half the staff can’t access email, someone’s shared calendar is gone, and the office manager is fielding panicked calls before 8 AM.
That’s not a scare tactic. It’s just what happens when migration is undersold.
This post is for decision-makers who want the real picture before committing. If you’re weighing a move to Microsoft 365 — or finally upgrading from a patchwork of legacy systems — here’s what the process actually looks like.
What “Migration” Actually Covers
When most people picture an M365 migration, they think: move email, done. In reality, a proper migration touches a lot more than the inbox.
The obvious stuff:
- Email accounts and mailbox history
- OneDrive and SharePoint file storage (often migrating from a local server or Google Drive)
- User accounts, passwords, and access levels
- Microsoft Teams setup and licensing
The stuff people forget until it breaks:
- Shared mailboxes — info@, billing@, support@ — these need to be rebuilt and re-permissioned
- Distribution lists and security groups — who gets what email, who can access which folders
- Room and resource mailboxes — conference rooms, shared calendars for equipment
- Legacy applications — line-of-business software that authenticates against your old email system or Active Directory
- Mobile devices — every phone and tablet needs to be reconfigured, often manually
- Third-party integrations — your CRM, your ticketing system, your accounting software — anything that talks to your email or file storage
This is where migrations get complicated. It’s not the mailboxes themselves. It’s everything attached to them.
Realistic Timeline: 20–100 Person Company
A well-run migration for a company your size takes two to six weeks, from kickoff to stable operation. Here’s why.
A smaller organization (20–30 people, clean environment, no legacy apps) can realistically land closer to two weeks. A mid-size company (50–100 people) with a mix of old and new systems, custom configurations, or regulated data requirements should plan for four to six weeks minimum.
Anyone quoting you “over a weekend” is either migrating email only, planning to skip the hard parts, or setting you up for a rough Monday morning.
The timeline breaks down into three distinct phases.
The Three Phases
Phase 1: Planning (1–2 Weeks)
This is the phase most people want to skip. It’s also the phase that determines whether the rest goes smoothly.
Good planning includes: a full inventory of what you’re migrating (users, licenses, shared resources, apps), documentation of your current environment, decision-making on folder structure and permissions before the move, and a communication plan for your staff.
Honest disruption assessment: Minimal — for end users. For IT and leadership, this phase requires real time and real decisions. Skimping here shows up later as problems that cost two or three times as long to fix.
What gets missed in rushed planning: nobody documents the shared mailboxes until they’re gone, nobody maps out which apps depend on on-premises Active Directory, nobody tests whether the third-party fax-to-email service works with the new domain.
Phase 2: Migration (1–2 Weeks)
This is when data actually moves. Email migration runs in the background — often for several days for larger mailboxes — while user accounts are created, licenses assigned, and SharePoint or OneDrive is populated from your existing file server or storage.
Good migration practice includes running a pilot group first (more on that below), doing the heavy lifting after hours, and leaving existing systems running in parallel until everyone is confirmed live on M365.
Honest disruption assessment: Moderate. Even with after-hours migration windows, end users will have a transition day — usually one full workday — where they’re switching from old systems to new ones. Some people will need help. Outlook profiles need to be set up. Mobile devices need to be reconfigured. This is expected. It’s not a sign something went wrong.
What goes wrong here: mailbox migrations that stall on large attachments, permissions that looked right in the old system but weren’t documented correctly, and apps that were authenticating against something that no longer exists.
Phase 3: Stabilization (1–2 Weeks)
Migration day isn’t the end. The two weeks after cutover are when the real issues surface — the shared calendar that’s missing a delegate, the mobile user who never got set up, the PDF software that can’t find the shared drive anymore.
Honest disruption assessment: Low, but real. Most disruptions in this phase are one-off issues for individual users. If your MSP is paying attention, they’re getting resolved in hours, not days. If you’re on your own with documentation, they pile up.
This phase also includes training — making sure your team knows how to use the tools they now have. M365 is more capable than most legacy systems, but only if people know how to use it.
What Will Break (Something Always Does)
Here’s the honest list of things that commonly go wrong, even in well-run migrations:
- Outlook profiles — The old profile doesn’t automatically become the new one. Some users need manual reconfiguration, especially on older workstations.
- Mobile devices — iPhones and Android devices need to have the old email account removed and the new one added. This usually requires someone to walk through it with each affected user.
- Shared calendars — Delegate permissions don’t always migrate cleanly. Executive assistants who manage calendars for leadership often hit this on day one.
- Third-party app integrations — Anything that sends email through your domain (your website contact form, your CRM, your accounting software) will likely need SMTP relay or connector settings updated.
- Legacy on-premises apps — Software that authenticates against an old Exchange server or local Active Directory needs to be evaluated before migration, not after.
None of these are catastrophic if you know they’re coming. They become catastrophic when your MSP handed you a migration doc and went quiet.
How to Minimize Disruption
The businesses that come through migrations with the least pain share a few common practices:
Run a pilot group first. Pick five to ten people across different roles and departments. Migrate them first. Find out what breaks. Fix it before it happens to everyone.
Migrate after hours. Cutover should happen when your staff isn’t trying to work. Friday evening into a weekend is typical. This gives you Saturday and Sunday to resolve anything unexpected before Monday morning.
Communicate early and often. Your staff shouldn’t learn about the migration the day it happens. A simple timeline — “here’s what’s changing, here’s when, here’s what you’ll need to do” — goes a long way toward keeping Monday morning manageable.
Plan for a training window. Even one hour with your team covering the basics of Outlook, Teams, and OneDrive prevents a week of individual help desk tickets.
Don’t cut the old system off immediately. Keep read-only access to old email available for two to four weeks post-migration. Someone will need to find something.
What Good MSP Support Looks Like During Migration
The difference between a smooth migration and a rough one often comes down to what your MSP does on cutover day and the week after — not just what they planned in advance.
Good support looks like: someone available on cutover day (not just on-call, actually available), proactive outreach to users who haven’t connected yet, same-day response to issues in the stabilization window, and a clear escalation path when something unexpected surfaces.
What it doesn’t look like: a migration doc, a Zoom call a week before, and a ticket queue.
At K&E Consulting, we treat migration day like a deployment event — dedicated time, dedicated focus, and someone on the line until your team is stable. We’ve done this enough times across the Twin Cities and greater Minnesota to know where things go sideways, and we build our process around catching those problems before they become your Monday morning.
Ready to Know What You’re Actually Getting Into?
If you’re considering a move to Microsoft 365, the worst thing you can do is go in without a clear picture of your current environment — what you have, what needs to move, and what might break.
We offer a free Migration Readiness Assessment for Minnesota businesses. In about an hour, we’ll walk through your current setup, identify the complexity factors specific to your environment, and give you an honest timeline and scope — before you commit to anything.
No obligation. No pitch deck. Just a straight answer about what migration would actually look like for your organization.
Schedule Your Free Migration Readiness Assessment
Or call us directly. We’re in Minnesota, we pick up the phone, and we’ll tell you the truth about what you’re looking at.
K&E Consulting provides managed IT services, Microsoft 365 support, and cloud migration services to businesses throughout Minnesota. Based in the Twin Cities metro.