Migrating 300 people to SharePoint in six weeks

Most SharePoint migrations don't run late because the tooling failed. They run late because nobody decided what "done" looked like before the files started moving. We've now done this enough times that the pattern is boring — and boring is exactly what you want when 300 people depend on finding a document on Monday morning.

Here's the migration we run, roughly in the order we run it. The specifics change with every tenant, but the sequence almost never does.

Start with an inventory, not a migration tool

Before touching a single migration utility, we map what actually exists. Not the org chart's version of the file share — the real one. The 14 folders called "Final", the 9 GB of installer ISOs someone saved in 2019, the three competing copies of the employee handbook.

A typical 300-person shared drive is 60–70% dead weight: duplicates, abandoned projects, files no one has opened in three years. Moving that wholesale just means you've paid to relocate the mess. We tag everything into three buckets — migrate, archive, delete — and we get a real human from each department to sign off on their slice. That sign-off is the single biggest predictor of whether the project goes smoothly.

Decide the information architecture before you move anything

The biggest mistake teams make is recreating their folder tree one-for-one in SharePoint. SharePoint isn't a deeper filing cabinet; it's a different model. Sites map to teams or workstreams. Libraries hold documents. Metadata — not nested folders — is how people find things.

So we design the destination first:

One hub site that ties the intranet together and gives you consistent navigation and search across everything.
A site per department or function, not per project — projects come and go inside a site.
Content types and columns for the documents that matter: a contract has a client, a value, a renewal date. Those become filterable metadata instead of being buried in a filename like Acme_contract_FINAL_v3.docx.

This is the part that takes a workshop, not a tool. It's worth every hour.

Governance is a decision, not a feature

"Who can create a site?" "What happens to a site when the project ends?" "Where do external partners land?" If you don't answer these up front, you get sprawl — the exact thing you migrated away from, rebuilt in the cloud within a year.

We set a small number of rules and enforce them with templates: a standard site design, a naming convention, sensible default permissions, and a lifecycle policy so dead sites get archived instead of accumulating. It's ten decisions that save you a cleanup project later.

What the six weeks actually look like

Weeks 1–2: content inventory, departmental sign-off, and the information-architecture workshop. Nothing moves yet.

Weeks 3–4: build the hub and sites, configure content types and permissions, and run a pilot migration with one willing department. Fix what breaks on a small group.

Weeks 5–6: migrate in waves by department, run training sessions, and cut over. The old drive goes read-only — not deleted — for a safety window.

The cut-over that doesn't wake anyone up at 2am

We never do a big-bang migration over a weekend and pray. We migrate in waves, department by department, with the old shared drive flipped to read-only rather than switched off. That single choice removes most of the risk: if something didn't come across cleanly, the original is still right there, untouched, for a few weeks.

Each wave gets a short, practical training session — 30 minutes on "here's where your stuff is now and how to find it" beats a 40-page PDF nobody opens. People don't resist SharePoint because it's hard. They resist it because someone moved their cheese without telling them where it went.

A migration is a change-management project wearing a technical costume. Treat it that way and the technology is the easy part.

What we'd tell you to do differently

If you're planning your own move, three things matter more than the tooling you pick:

Get departmental owners to delete their own junk first. It's faster than any migration tool and it's the only cleanup that sticks.
Design the destination before you schedule the move. The folder-for-folder copy is a trap that costs you the whole benefit of SharePoint.
Keep the old drive read-only for a month. It turns a high-stakes weekend into a calm, reversible rollout.

Done this way, six weeks is realistic for a few hundred people — and you come out the other side with an intranet your team actually wants to use, not just a more expensive place to lose files.