Migrating SharePoint without stopping the business

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 on global farms at the European Commission, on the publishing intranet of the Irish government, and on migrations from on-premises to SPFx for Fortune 500 clients. The same pattern comes up every time.

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 right then. It does not matter that the file exists somewhere. For that person, at that moment, the system failed. That is where trust goes, and trust 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 of them, and which carry permissions nobody can explain. In our experience, a good deal 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 in which 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 on 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.