Microsoft 365 Migration: How Long It Really Takes and What Goes Wrong

Microsoft 365 migrations have a reputation for being either trivial or a disaster, and the difference is almost always preparation rather than technology. Here is a realistic view of how long one takes, what happens at each stage, and the problems that come up most often.

Realistic timelines

Measured from first conversation to the old system being switched off:

• 1 to 10 users, email only: 1 to 2 weeks. The cutover itself is usually a single evening.
• 10 to 50 users, email plus files: 3 to 6 weeks. File migration is the long pole, not email.
• 50 to 150 users, email, files and a server to retire: 6 to 12 weeks.
• Anything with a line-of-business application tied to the server: add 4 weeks minimum, and do the application first.

The active work is a fraction of that. Most of the elapsed time is data copying in the background and waiting for people to be available.

The phases

1. Discovery (2 to 5 days)

What mailboxes exist, how big they are, what shared mailboxes and distribution lists are in use, where files live, how much data there is, who owns the domain, and what depends on the current system. Skipping this is the most common cause of a bad migration.

2. Preparation (3 to 10 days)

Tenant setup, licence assignment, security baseline, and crucially a pre-stage of the data. Modern migrations copy the bulk of mail and files while the old system is still running, so the final cutover only has to move what changed.

3. Pilot (2 to 5 days)

Move a small group first, ideally including someone technical and someone who uses the system heavily. This is where you discover the odd workflow nobody mentioned.

4. Cutover (one evening or weekend)

DNS is repointed, final delta sync runs, and clients are reconfigured. This is the part everyone worries about and it is usually the calmest, provided the first three phases were done properly.

5. Aftercare (1 to 2 weeks)

Expect a spike in small issues in the first few days. Signatures, printers scanning to email, a shared calendar permission, a phone that will not reconnect. Budget support time for this, because it is normal and it is where the perception of success is decided.

What goes wrong

1. Nobody controls the domain

The migration stops dead at cutover because the DNS is with a web designer who left in 2019, or an old provider who is slow to respond. Confirm domain access in week one, not on cutover night. This is the single most common delay.

2. PST files hiding on desktops

Years of archived mail sitting in local PST files on individual machines. They are invisible to a server-side migration and users assume they will come across. Find them during discovery by checking machines, not by asking.

3. Shared mailboxes migrated as user mailboxes

This works, and then generates an unnecessary licence bill every month afterwards. Shared mailboxes under 50GB do not need a licence. Get the classification right during discovery.

4. Public folders

If the old system uses public folders, that is a project of its own. Decide early whether they become shared mailboxes, SharePoint, or Teams, because each behaves differently and users need telling which.

5. Deep folder structures and long file paths

File shares built over fifteen years often contain paths too long for OneDrive and SharePoint to sync, plus characters that are not permitted. These fail quietly in bulk. A pre-migration scan should catch them so they can be fixed or flattened before the copy, not during it.

6. Mail flow to line-of-business applications

The accounting system that emails invoices, the CRM that sends notifications, the scanner that emails PDFs to the office. All of them authenticate to the old mail server and all of them break at cutover. List every device and application that sends email during discovery. Multifunction printers are the ones most often forgotten.

7. Multi-factor authentication introduced on cutover night

You should absolutely enable MFA. Do not enable it in the same change window as the migration, or you will not know which of the two caused the queue at the helpdesk. Migrate first, then roll MFA out as its own piece of work a week or two later.

8. No plan for the old system

Keep the old mailboxes and data available in read-only form for a period after cutover. It costs very little and it removes the pressure of "did everything come across?" Decommission once people have stopped asking, not on the day.

What a good migration feels like

Users are told what is happening and when, in plain language. They keep working during the pre-stage. The cutover happens outside business hours. On Monday morning Outlook asks for a password once, and everything is there. Small issues are dealt with quickly for a week or two, then it goes quiet.

That outcome comes from the discovery phase, not from clever tooling. The migration itself is largely a solved problem. Knowing what you are migrating is the part that still requires care.

Should you move at all?

If you are running an on-premise server purely for email, yes, almost certainly. The maintenance, the backup burden and the security exposure are difficult to justify now.

If you have a line-of-business application that needs a server, the answer is more nuanced. Moving email and files to Microsoft 365 while keeping a smaller server, or moving that server to a hosted environment, is often the sensible middle path.

Talk to us

We have run these for businesses across London and the South East. If you want a realistic timeline for your setup, and an honest view of whether it is worth doing now, call 0207 112 4812.