How do you move a file server to SharePoint?

Design the destination before moving anything, archive what nobody has opened in years, then migrate in stages with the old share left read-only until each stage is proven. The copying itself is largely automated. The value is in deciding the structure, and the failure is tipping a decade of folders in unchanged.

Almost every unhappy SharePoint story starts the same way: a business copied its file server across without changing the shape, and then concluded the product was the problem. It usually was not. A shared drive's structure evolved over years under no particular design, with permissions bolted on folder by folder, and reproducing that inside SharePoint imports every accumulated problem while adding a less familiar interface. The migration is the one chance to fix it, and it is genuinely much harder afterwards.

Start with an inventory of what is actually there, and let the numbers guide the conversation. How much data, how many files, how deep the folders go, and, most usefully, when things were last opened. Nearly every business finds that a large share of its file server has not been touched in years. That material does not need migrating into live storage; it needs archiving somewhere cheaper and searchable, which shrinks the project, speeds every subsequent step and improves what people see afterwards.

Then design the destination, which means sites rather than folders. Anything needing its own access list becomes its own site with named owners: finance, HR, each major client or project, a company-wide area. Folders inside stay shallow. Agree a naming convention before creating anything. This is also the moment to resolve the permissions questions everyone has been avoiding, because you are about to write them down explicitly, and discovering that nobody agrees on who should see the contracts folder is better handled now than after the move.

Clean up before migrating, not after. Delete the obvious rubbish, archive the dormant material, and resolve duplicates where you reasonably can. Run a pre-migration scan for path lengths and unsupported characters, since SharePoint has limits a file server does not, and long nested paths are the most common cause of files silently failing to arrive. An hour of scanning prevents the classic outcome where the migration reports success and three hundred files did not make it.

Migrate in stages, and department by department is usually the right unit. Each stage gets a bulk copy while the old share is still live, then a short cutover of the changes since, then verification by people who actually use those files rather than by whoever ran the tool. Keep the old share available read-only afterwards, for a month at least, because it is both your rollback and the place the forgotten thing turns out to live. Setting it read-only matters: leaving it writable guarantees someone keeps saving there and you now have two divergent copies.

Plan the human side alongside the technical one, because this is a change to how everyone works rather than a background upgrade. Show people where their material now lives, sync the libraries they need so those appear in File Explorer beside OneDrive, and explain the two rules that matter: business documents go in the site, personal drafts go in OneDrive. Half an hour with each team in the week of their move prevents most of the support calls, and the calls you avoid are the ones that would otherwise become resentment.

Decide what happens to the permissions you are about to recreate, because a migration is the only convenient moment to correct them. On the old server, access accumulated over years: the contractor added in 2021, the folder opened up for a deadline and never closed, the group nobody can define. Copying that faithfully into SharePoint imports every one of those decisions and makes them harder to see. Export the existing permissions, have the awkward conversation about who should actually have access, and build the new sites from the answer rather than from the history.

Two things to settle before you finish. Backup, because Microsoft protects the platform and your content remains your responsibility, and a migration is exactly when someone should confirm the new location is covered. And the old server, which should be decommissioned deliberately once you are confident: export anything to be retained, destroy the data securely, and document what was destroyed and when.

The honest caveat is that this is more work than the sales version suggests, and the extra work is almost entirely decision-making rather than technology. A business that will not engage with the structure questions is better served by a straight copy and low expectations than by a half-designed migration nobody owns. If you want it planned and staged properly, call 1800 456 567.