Migrating SharePoint without stopping the business
The hard part of a migration is not moving files. It is that nobody stops working while they move.
There are two ways to run a SharePoint migration. One is to pick a weekend, switch everything off, copy, and pray. The other is to accept that the business cannot stop, and design the migration around that fact.
We have done the second one on global farms at the European Commission, on the publishing intranet of the Irish government, and on on-premises to SPFx migrations for Fortune 500 clients. The pattern always repeats.
What you learn to look at differently
The natural instinct is to treat migration as a data transport problem. We treated it that way too, at first. It is not. It is a continuity problem.
The files always arrive in the end. What ruins a project is the day a team opens the portal and cannot find the document they need at that moment. It does not matter that it exists somewhere. For that person, at that instant, the system failed. And that is where trust is lost, which is far more expensive to recover than any file.
What we do before moving a single byte
A real inventory. Not counting sites. Understanding which ones are alive, which no one has opened in years, who owns each, and which carry permissions nobody can explain. A substantial share of what you find should not be migrated at all. It should be archived or deleted, and that is a business decision, not a technical one.
A dependency map. Flows, forms, customisations, integrations somebody built seven years ago that still feed a report the board reads every Monday. This is where the surprises live.
A decision on the legacy. Classic web parts will not survive. The question is not how to convert them, it is whether they are worth converting. Often the honest answer is no.
Waves, not a big bang
You move in groups with clear boundaries: one department, one function, a set of sites with the same owner. Each wave has a period where source and target coexist, with the source read-only. If something breaks, nobody is left unable to work: you roll back one wave, not the whole project.
This is slower on paper. It is far faster in reality, because there are no unplanned stoppages.
What you gain by working this way
You earn the right to fail small. In a big bang migration, the first mistake is public, it is large, and it reaches the top of the organisation the same day. In waves, the first mistake affects thirty people, is fixed in a morning, and the next wave does not repeat it.
Nothing is left to chance. That is the difference between a migration remembered for its outcome and one remembered for its weekend.
