How much does a Microsoft 365 migration cost and how long does it take?

Two businesses with forty staff each can be a straightforward weekend and a three-month project respectively. The difference is almost never the number of people. It is what you are moving from, how tidy it is, and how much of it nobody understands any more.

This is an explanation of what genuinely drives the number, so you can judge whether a quote you have been given is realistic.

Why user count is a poor guide

Per-user pricing is popular because it is easy to quote, and it works reasonably for the mailbox part of a move. Mailboxes are predictable: they are all the same shape, and moving four hundred is not much harder per mailbox than moving forty.

Everything else scales with mess, not headcount. A ten-person business with fifteen years of files on an old server, a shared drive full of permissions granted individually, and a line-of-business application that emails from a fixed address is a harder job than a fifty-person business that already lives in the cloud.

What actually drives the cost

Where you are moving from

Ranked roughly from easiest to hardest:

• Another Microsoft 365 tenant. Well-trodden, good tooling, though identity and domain cutover need care.
• Hosted Exchange or a POP/IMAP provider. Usually straightforward for mail, with the wrinkle that older providers sometimes throttle heavily, which stretches the calendar without adding work.
• Google Workspace. Mail and files migrate well; the friction is in the format differences and in shared drive permissions, which do not map one-to-one.
• On-premises Exchange. More moving parts, particularly if you want a hybrid period rather than a single cutover.
• A file server with years of history. Frequently the largest single piece of work, and the one most often underestimated.

How much data, and how much of it should move

Volume affects duration more than cost, since copying is largely unattended. The expensive question is what deserves to move. A file server holding two hundred thousand files usually contains a lot that should be archived rather than migrated, and deciding that requires someone who knows the business.

A useful rule: if nobody has opened a folder in five years, it is archive, not migration.

Permissions

This is the part that quietly consumes time. On an old file server, permissions have typically been granted person by person over years, with exceptions layered on exceptions. Recreating that faithfully in SharePoint is both difficult and usually the wrong goal, because you would be paying to preserve a mess.

The better approach is to design a permission structure around roles, then map the old access to the new structure. That is a decision-making exercise more than a technical one, and it is where a migration either becomes a genuine improvement or just relocates the problem.

The exceptions

Almost every migration has two or three of these, and they set the difficulty:

• A shared mailbox half the company depends on in a way nobody documented
• An application that sends email and needs reconfiguring, often one nobody has the password for
• A scanner or copier that emails scans to a folder
• Public folders
• A bespoke database that reads files from a specific path
• Distribution lists maintained by hand for a decade

How the timeline usually breaks down

For a typical business of ten to fifty people moving from one mail system with a moderate amount of file data:

• Discovery, a few days to a week. Inventory of mailboxes, data, applications and dependencies. This is where the exceptions surface, and cutting it short is the most common cause of migrations going wrong.
• Design and preparation, one to two weeks. Tenant setup, identity, licence assignment, the target file structure, security baseline, and DNS planning.
• Pre-migration sync, a few days to a couple of weeks, mostly unattended. Bulk copying of mail and files while everyone carries on working normally.
• Cutover, a weekend. DNS change, final delta sync, testing. Scheduled so Monday morning is uneventful.
• Hypercare, one to two weeks. Close support while people hit the small things: a missing shortcut, a signature, a permission.

So elapsed time of three to six weeks, of which the disruptive part is one weekend. Complexity extends discovery and preparation rather than the cutover itself.

The things that make a migration harder

• No admin access to the current system. Surprisingly common where the original provider has gone quiet.
• Nobody owns the decisions. Migrations need someone internal who can answer "should this folder move" without convening a meeting.
• Trying to change everything at once. Combining a mail move, a file restructure, a new phone system and a device refresh in one weekend is how a project turns into an incident.
• Very large individual mailboxes or files. Fixable, but they need planning around.
• Poor internet at the office. Affects the initial copy more than anything else.

Where costs hide

Things people forget to budget for:

• Licences during overlap. You will briefly pay for both old and new.
• Data you keep for compliance. Retaining old mail may need archive licensing or a separate archive.
• Training. Usually small, and worth doing badly rather than not at all. An hour on where files now live prevents weeks of people saving to the desktop.
• Security configuration. A tenant that has been migrated but not secured is a job half done. Build the baseline in rather than treating it as a follow-up project.
• Decommissioning. Turning off the old server, ending the old contract, and keeping a readable copy of the old data for a while.

How to get a quote that survives contact with reality

Be wary of a fixed price offered before anyone has looked at your environment. That number is either padded to cover the unknowns or it will be revised once the unknowns appear.

The pattern worth looking for is a small, paid discovery exercise followed by a fixed price for the migration itself. Discovery costs a fraction of the project, and it is what makes the fixed price meaningful. It also gives you something useful even if you stop there: an inventory of what you have and what depends on what.

Questions worth asking whoever is quoting:

• What have you assumed about our file permissions?
• What happens to mail that arrives during the cutover?
• How long do we keep the old system available?
• Is security configuration included, or extra?
• What would make you come back and ask for more money?

That last question is the informative one. An honest answer tells you where the risk sits. A claim that nothing could change is not an answer.