Migrating SharePoint without stopping the business

Every SharePoint migration interrupts somebody. A plan that promises otherwise has not yet met its largest database, or the integration that writes into a library at two in the morning. The useful question is narrower: which work stops, for whom, for how long, and whether that was decided in advance or discovered on the night.

"Without stopping the business" is therefore a design target with numbers in it, not a promise. This analysis looks at what the target can mean when SharePoint Server 2016 or 2019 moves to Subscription Edition, and when it moves to SharePoint Online, because the mechanics differ enough that the same sentence commits a project to different things. The ordered procedures are in the Field Guide, in chapter 9, on cutover, and chapter 8, on verification. This page is about the decisions those procedures assume have been taken.

Name the interruption before choosing the method

Two kinds of continuity are routinely confused. Read continuity means people can still find and open what they need. Write continuity means they can still add and change it. Most estates can keep reading through almost the whole move. Writing is what has to be fenced, because a write that lands on the wrong side, or in the gap between two copies, is the one that goes missing.

The unit that matters is a piece of work, not a site. A finance library during the month-end close, a case-file list that a regulator expects to be answered from within a day, a team that publishes every morning: each has a tolerance, in minutes, hours or days, and a time of the month when it is least used. Writing those tolerances down, per group of sites, turns "without stopping" into something a rehearsal can measure and an owner can accept.

Most interruptions people actually feel are not technical failures. A bookmark points at the old address. A sync client keeps editing a copy of a library nobody reads any more. A permission that existed on the source did not arrive. The files are all there, and the person still cannot do their work. Those are the interruptions worth designing out first, because they are the ones a migration report does not count.

Two destinations, two kinds of continuity

Subscription Edition: the database is the unit

The only upgrade path from SharePoint Server 2016 or 2019 to Subscription Edition is a database attach, which upgrades content and not configuration. Microsoft's procedure keeps the old farm readable while the databases move: it sets them to read-only before the backup, and states that "if the databases are set to read-only, users can continue to view content. However, they will be unable to add or change content."

So on this destination continuity means full read access and a write freeze per content database. The freeze runs from the moment a database is set read-only until the new farm takes over: backup, copy, restore, set back to read-write (a read-only database cannot be upgraded), attach, and whatever checks the plan requires before users are pointed at it. There is no item-level catch-up afterwards. A change made on the source after its backup is not in the new farm, which is why the read-only setting is the safeguard and not a courtesy.

Three consequences follow, and all three are visible in Microsoft's documentation:

• The largest databases set the window. Content databases can be attached in parallel, with the start of each session several minutes after the previous one. A single very large database still takes as long as it takes, and the freeze of everything in it lasts that long. If one database dominates the window, the honest options are to accept it, to give its attach and freeze a window of its own, or to reorganise it on the source farm beforehand, which is a change with its own test. A window of its own does not give it a cutover of its own: every database behind one web application's address changes over together, unless the site sits behind an address of its own.
• Search is handled separately. Microsoft advises not to set the search databases to read-only at the copy stage, so that search keeps working until the search service application is upgraded.
• The address can stay the same. Microsoft's guidance is to recreate each web application with the same URL, because with a different one Office applications might not be redirected and bookmarks stop working. A farm-to-farm move that keeps its addresses removes the largest source of felt interruption in the other kind of migration.

Rollback on this destination is the read-only source and the backups, which Microsoft keeps for the case where you "must enable the original farm again". That remains a clean option only while nobody has written on the new farm. After the first write, going back means either losing that write or carrying it back by hand, which is the question chapter 9 answers per write state.

SharePoint Online: the copy runs while people work

Moving to SharePoint Online uses a migration tool rather than a database attach, and the tools are designed to run while the source stays in use. For a SharePoint Server farm, Microsoft's tool is the SharePoint Migration Tool, which can rerun a task to copy "only those new or updated files in the source location". Migration Manager calls the same idea a delta sync, but it reads file shares and cloud sources, and "doesn't support the migration of content from SharePoint Server" (checked on 7 November 2026).

Continuity here looks different: people keep writing on the source while a first copy and then reruns bring the destination up to date, and the write freeze shrinks to the last rerun before cutover. The price is a period in which two writable systems exist, and the documented rules for reruns say where they can diverge, and where they are silent:

• A file changed on both sides is not overwritten when the destination copy is newer. Work done in the destination early is kept, and so is the conflict it creates.
• A permission change on its own is not documented as carried. A rerun of the SharePoint Migration Tool decides by each file's modified time, and Microsoft's page does not say what happens to a permission changed on an unmodified file. For its own sources, Migration Manager migrates permissions only when the file itself is migrated again. Treat permission changes made during coexistence as not carried until a test rerun shows otherwise.
• A deletion is not carried. In a file share migration, a file removed from the source remains in the destination; for a SharePoint Server source, Microsoft's rerun page does not say.
• Renaming or moving migrated files before the final run overwrites them. Microsoft strongly recommends against it, in both tools' documentation.

Correction, 7 November 2026. An earlier version of this section applied Migration Manager's rerun rules to SharePoint Server, which Migration Manager does not read; the permission rule above now says what is and is not documented for each tool.

None of these is a defect. They are how a copy that runs while people work behaves, as far as Microsoft documents it, and a plan that relies on reruns has to say which of them matter for each group of sites, and what will be done about them: a short freeze on permission changes, a deletion report from the source, an instruction not to reorganise during coexistence.

What usually interrupts people on this destination is the address. Every site and library has a new URL, so links inside documents, bookmarks, mapped drives, sync clients and integrations all point at the old place until someone changes them. That work is larger than the copy in many estates, and it is invisible in the copy tool's report.

What actually breaks continuity

When people say a migration "stopped the business", it is rarely because files did not arrive. It is usually one of these:

• Addresses. Links, bookmarks and synced libraries pointing at the source. On Subscription Edition this is avoidable by keeping URLs; on SharePoint Online it needs redirects, communication and an inventory of the integrations that write by URL.
• Identity and permissions. A classic-mode web application has to be converted to claims, because Subscription Edition content web applications support claims only, and the conversion leaves behind any account that is disabled or deleted in the directory. On SharePoint Online, every source account has to be matched to a cloud identity before its permissions mean anything there, and that matching is part of the inventory, not of the copy.
• Processes, not content. A list arrives intact while the process that ran on it does not. On Subscription Edition, SharePoint 2010 workflows and InfoPath Forms Services have been unsupported since 14 July 2026, and Microsoft's update notes say the SharePoint 2010 workflow feature will be disabled starting with the September 2026 update. A move that carries the content and not the process has stopped the business for whoever ran it.
• Writers outside SharePoint. Services that create items, scanners that file documents, integrations that update lists. They keep writing to the source unless they are pointed elsewhere, and a write fence that forgets them is not a fence.
• Search and navigation. People find things by searching. A destination whose index is still being built is a destination where the content exists and cannot be found.
• People. A change nobody explained reads as a loss. Microsoft's own migration guidance notes that when the way files are shared changes, "many users ... claim, 'My files are lost!'", about files that are in the new place.

Each of these belongs in the inventory before the first byte moves, with an owner. The dependency map is where the surprises live: the integration somebody built years ago that still feeds a report read every Monday is found either during the inventory or on the Tuesday after cutover.

Waves, and when a single window is the right answer

Moving in waves limits the damage of a mistake to one wave, and lets each wave learn from the last. The boundaries matter more than the number of waves. Sites that write to each other, share a process or share an integration move together, because splitting them creates exactly the cross-system writes the plan is trying to avoid. Ownership is the second boundary: a wave whose owners are available to accept it is a wave that can finish. The first waves are best chosen to teach rather than to impress, being representative of the estate and forgiving if something goes wrong.

A single window is not a reckless choice when it has been measured. A modest farm moving to Subscription Edition, with addresses kept and a rehearsed attach that fits a weekend with margin, may be best done in one planned window. Waves would add coexistence, two systems to support and more communication, for no reduction in risk. The rule is the same in both cases: rehearse the move on copies, measure the freeze, and choose waves when the measured freeze does not fit the agreed tolerance.

Rehearse, measure, then promise

A rehearsal on copies of the production databases or sites is where the numbers come from. On Subscription Edition it gives the duration of each backup, copy, restore and attach, and runs Test-SPContentDatabase against each database to list the customisations the new farm is missing, which Microsoft names as a frequent cause of upgrade failure. On SharePoint Online it gives the duration of the first copy and of a realistic rerun, and the list of items the tool could not copy.

The interruption announced to the business should come from that rehearsal, with the slowest component named. "Saturday from 18:00 to Sunday 14:00, because the case-file database takes eleven hours to copy and attach" is a statement an owner can plan around. "A weekend" is not.

Verification belongs in the same rehearsal. A migration report is written by the tool that did the moving, and the only independent check is a comparison against a read of the source taken before the move, which chapter 8 describes and which the open source migration verification contract defines. It compares two reads today, and its reader for SharePoint Online libraries has not yet been recorded running against a real one.

Rollback is a window, not a button

Rollback is clean only while the destination has accepted no writes. On Subscription Edition the read-only source and the reserved backups are the way back. On SharePoint Online the source itself is, until people start working in the destination. After the first write in the new place, going back means choosing between losing that work and carrying it back, and chapter 9 sets out that choice for each write state. A plan that says "we can always roll back" without saying until when has not decided anything.

What this costs

Designing for continuity is slower on the calendar. Waves mean coexistence: two systems to support, reruns and verifications per wave, communication per wave, and owners who must be available to accept each one. The cost is worth paying where the tolerance is tight and the estate is large. It is not worth paying everywhere, and pretending otherwise turns a two-day move into a three-month programme.

What makes the difference is not a particular method. It is that the interruption was chosen, measured, explained to the people affected, and verified afterwards against evidence taken before. Every team that has run a migration has learnt some of this the hard way, ourselves included, and the documentation Microsoft publishes for both destinations is the best guide to where the hard ways are.

Where to go next

• Chapter 9: cut over without losing the truth and chapter 8: verify what actually moved, for the procedures.
• Migrating 2016 and 2019 to Subscription Edition: the scripts, for the database-attach sequence.
• SharePoint 2016, 2019, Subscription Edition and Online: what actually changes, for what each destination supports.
• The SharePoint Compass, for a first read of an estate's destination and risks.

Tags#sharepoint#migration