A file migration that goes badly almost never goes badly on the weekend itself. It goes badly because of three or four decisions taken weeks earlier, usually about things nobody measured.
Done in the right order it is dull, which is the goal.
Measure three things before planning anything
Total size is the number everyone quotes and the least useful of the three.
File count matters more. A hundred gigabytes in two hundred files copies quickly. The same hundred gigabytes in four million small files takes far longer, because the time goes on per file overhead rather than throughput.
Path length and folder depth matter next. Long paths, and characters that were acceptable on an old server but are not accepted by the destination, are the most common cause of a copy finishing with a list of failures.
All three are available from a single scan, and running one is the cheapest hour in the whole project.
Clean before you move, not after
Every organisation carries files nobody has opened in years. Old projects, three copies of the same folder, an archive of a system replaced in 2018.
Carrying that across costs copy time, storage and years of clutter. Removing it afterwards never happens, because once it is there it looks like it belongs.
Sort by last accessed date and look at the bottom. Anything untouched for several years goes to a separate archive location rather than into the live workspace. Archive rather than delete, and put a date on when it can go.
Decide what is not moving
Some things should stay where they are. Files that an application holds open. Databases. Anything a piece of equipment writes to directly. Very large working files opened all day by people in one building.
Deciding this in advance is what turns a migration into a plan rather than an argument on the Sunday. Write the list down and tell the people affected.
Copy twice, not once
The copy runs in two passes.
The first pass runs in advance, while everyone is still working normally, and moves the bulk of the data. It can take days, and that is fine because nothing depends on it yet.
The second pass runs in the changeover window and only copies what changed since the first. It takes a fraction of the time, which is what makes the window short enough to fit in an evening rather than a weekend.
Run a third, throwaway pass a few days before the real one. It is the only reliable way to find the permission and path problems while there is still time to fix them.
Sort out permissions before the move
Most file stores have accumulated permissions nobody can explain. Individual people granted access directly, groups that contain one person, folders where inheritance was broken for a reason lost to history.
Copying that across faithfully copies the problem. Tidy it first, at the top two or three levels at least, and express access as groups rather than people.
This is also the moment to find out what the wrong people can currently see. That discovery is uncomfortable and much better made now than in an audit.
Keep the old server, read only, for a month
After the changeover, make the old location read only rather than switching it off. Do not delete anything.
Somebody will need a file that did not come across, or will want to check that a folder matches. A read only copy answers both in a minute. It is the cheapest insurance in the whole exercise, and a month is usually enough.
Set a date to decommission it, and put that date in writing, or it will still be humming in the cupboard in two years.
Tell people what changes for them
From a user’s point of view the only question is where their files are now and whether the shortcut on their desktop still works.
Send two paragraphs before the change and one screenshot of the new location. Keep the same folder names where you can, because renaming and relocating in the same weekend doubles the confusion for no benefit.
We plan and run these migrations for the organisations we support. There is more on our cloud and Azure page, with related detail on Microsoft 365 and backup and disaster recovery. If you are weighing one up, tell us how much data you hold and we will say what we would measure first.