File Server to SharePoint: The Complete Migration Checklist

Moving your file server into SharePoint is a one-way door. Get it right and nobody ever asks for the old drive back. Get it wrong and you've simply relocated the mess to the cloud — same chaos, new address. This is the checklist we work through on every migration, in the order that actually works.

Here's the thing most migration guides won't tell you: the copying is the easy part. Modern tools move files reliably. The parts that decide whether your migration succeeds happen before the first file moves — deciding what deserves to move and where it should live — and after the last one lands, when your team either adopts the new home or quietly drifts back to old habits.

Work through these phases in order. Each one exists because skipping it gets expensive later.

01Inventory and audit what you actually have

You can't plan a move without knowing what you own

Before you touch anything, point an inventory tool at the file server — a disk-reporting utility, or the pre-migration scan built into your migration tool — and get the full picture. Most businesses are genuinely surprised by what's sitting on that server.

• Total size, file count and file types per share and per top-level folder
• Last-modified dates — how much of this hasn't been opened in years?
• Duplicates and obvious junk: old backups, installers, exported copies of copies
• A permissions map: who can access each share today, and who actually should

This audit drives every decision that follows — your destination design, your tooling choice, your timeline. It's also where you make the single most valuable call of the whole project: deciding what doesn't move. Dead content gets archived, not migrated.

02Design the destination before you migrate anything

SharePoint is not a bigger folder

The biggest mistake in file-server migrations is treating SharePoint as a destination drive and copying the folder tree across as-is. SharePoint is organised differently: sites for each team or function, document libraries within them, metadata columns and views instead of folders nested ten levels deep, and permissions set at the site or library level — not scattered across hundreds of folder exceptions.

So design the destination on paper first. Which sites will exist? Which libraries live in each one? Where do permissions genuinely need to differ? What becomes a metadata column instead of another layer of nesting? A department share usually becomes a site; its major folders become libraries; the deep structure underneath flattens out.

If you're planning to give your team a proper landing page, news and navigation at the same time, this is exactly the moment to do it — destination design and intranet design are the same conversation. That's the heart of our intranet design and migration service, and it's the phase where an experienced pair of hands saves the most pain.

03Choose your tooling: SPMT vs ShareGate

Free and capable, or paid and comfortable

For most file-server migrations the shortlist is two tools: Microsoft's free SharePoint Migration Tool (SPMT) and ShareGate, the best-known paid option. Both move files, both preserve modified dates and authors, both support incremental passes. The differences show up when your migration gets complicated.

Our honest take: if your audit shows a tidy server and your destination design is simple, SPMT will do the job for free. If the audit shows complexity — deep nesting, messy permissions, lots of restructuring — ShareGate's license fee is usually cheaper than the cleanup you'd otherwise do by hand.

04Pilot with one department

One team, end to end, before you commit the company

Don't migrate the whole business in one go. Pick one department — ideally friendly, moderately complex, and not in the middle of their busiest season — and run their migration end to end: audit, restructure, migrate, cut over, support.

The pilot is where the theory meets reality. You'll find the permission edge cases, the files with impossible names, the Excel workbook everyone depends on that links to six others, and the training questions you didn't anticipate. Fix the process, not just the data — every problem the pilot surfaces is one the full rollout won't have. It also converts your plan into a realistic timeline you can actually commit to.

05Migrate in waves with delta sync

Copy everything while everyone keeps working

Here's the technique that removes almost all the pressure: run the big initial copy while the old file server is still live. Nobody stops working, nothing is down, and it doesn't matter how long the first pass takes.

Then, as cutover approaches, run delta syncs — incremental passes that pick up only the files added or changed since the last run. Each pass is smaller than the one before. By cutover day, the final delta is a short job instead of an all-night copy, and your cutover window shrinks from a risky marathon to a routine step.

06The cutover weekend

The moment SharePoint becomes the source of truth

Pick a quiet window — a weekend works for most businesses — and run the switch as a short, boring, well-communicated sequence:

• Announce the cutover date well in advance, then remind people the week before
• Run the final delta sync after close of business on the last working day
• Repoint mapped drives, shortcuts and any processes that reference old paths
• Publish a one-page quick-start: where things live now, and how to sync libraries to File Explorer
• Have someone visibly available on Monday morning to answer "where's my file?"

That last point matters more than it looks. The first week decides whether people adopt SharePoint or route around it, and a fast answer to the first confused question is worth more than any training video.

07Freeze the old server read-only

Keep the safety net, remove the temptation

Immediately after cutover, set the old shares to read-only. Not off — read-only. If the old drive still accepts writes, muscle memory will win and within a week you'll have two sources of truth, which is worse than the mess you started with.

Read-only gives you the best of both: anyone who panics can still go and look at the old server, but no new work can land there. Every path leads forward to SharePoint.

08Decommission on a date, not a vibe

The migration isn't finished until the server is gone

Set a decommission date at cutover time and hold to it. When it arrives: take a final full backup, confirm the archive is stored somewhere that satisfies your retention obligations, then shut the server down. A file server that lingers "just in case" for years is an ongoing cost, a security liability, and a quiet vote of no confidence in the new system. Turning it off is the point at which the migration is actually done.

---

The classic mistakes — and how this checklist avoids them

Every failed migration we've been called in to rescue made at least one of these mistakes. They're all avoidable.

The lift-and-shift folder dump

Copying the entire folder tree into one giant document library, structure and all. It technically works, and it fails in practice: search is poor because there's no metadata, permissions are chaos, and users see the same mess in a new place — so they conclude SharePoint is the problem. Phase 02 exists precisely to prevent this.

Migrating 15 years of junk

Paying — in time, storage and attention — to move content nobody will ever open again. If your audit shows files untouched for years, archive them to cheap storage and migrate only what's alive. A smaller migration is faster, cleaner and easier to adopt.

Path-length surprises

SharePoint limits the total length of a file's full URL, and a decade of nested folders with long, descriptive names will blow past that limit — usually discovered mid-migration when files mysteriously fail to copy. Both SPMT and ShareGate can flag risky paths before you run; flattening deep structures in your destination design solves the problem at the source.

Broken links

Excel workbooks that pull data from other workbooks by their old server path. Documents with embedded links to \\server\share locations. Desktop shortcuts, printer-scan destinations, and line-of-business apps writing to a share that no longer accepts files. Inventory the link-heavy files during your audit, fix the critical ones straight after cutover, and tell people how to report the rest.

One last piece of advice: treat the migration as the beginning, not the end. The businesses that get the most out of SharePoint keep tending it — naming conventions, permissions reviews, a bit of governance. There's more practical guidance on all of that over on our blog, and if you'd rather talk it through, get in touch.