Chapters 23 to 25 each take a destination. This one takes the answer that is not a platform: some sites and applications should not move at all, and each still has to go somewhere. Microsoft's migration guidance starts here: "What content really needs to be migrated? What can be left behind?" (migration performance guidance, checked on 6 November 2026). Chapter 3 set the question aside, because content nobody opens is volume, not a destination problem. This chapter answers it, site by site.
Which of your sites and applications would a migration copy without improving, and where does each of them go instead?
The decision this chapter leads to is a disposition for every site collection and application (migrate, archive, keep read-only or delete), with its evidence, the person who agreed it and, unless it migrates, the date its state ends.
Which sites and applications this chapter is for
Every site collection on a SharePoint Server 2016 or 2019 farm, whether it goes to Subscription Edition by database attach (Chapter 23) or to SharePoint Online by copy (Chapters 8 and 9). An application, here, is a site collection whose value is a process rather than its documents: lists, forms, workflows and code. Part III decides its parts; this chapter decides whether it goes anywhere at all. A component used only by sites that stay behind is retired, not rebuilt, as Chapter 19 does for workflows.
The unit is the site collection, because the locks, the site archive and the deletions below act on one. Online, you leave a site out of the migration tasks. On an attach, a site collection travels with its content database: delete it before that database goes read-only for the backup, or move it with Move-SPSite to a database you do not attach, which must already exist on the same SQL Server and web application (Move-SPSite, checked on 6 November 2026).
Four reasons to leave a site behind
Microsoft's planning guidance says unused or abandoned sites "use resources but don't deliver any business value" (plan for site maintenance, checked on 6 November 2026). Disuse is one reason of four, and each needs its own evidence.
Nobody uses it. Use means reads, and a last-modified date counts edits: a reference site read every week and never edited looks abandoned (last modified, and by whom). On a farm, the usage database keeps 14 days by default and 31 at most (Set-SPUsageDefinition), and the Popularity Trends report shows a monthly count for the last three years (view usage reports, both checked on 6 November 2026), once a farm administrator has configured usage collection (plan for site maintenance, above). The window has to cover the business cycle: a site read only at year end looks unused for eleven months. No data means use is not established, as Chapter 2 says, not that it was zero. The threshold is your convention, written down with its reason (Chapter 6).
It is kept only because something requires it. Content held for a retention schedule, a contract or a case belongs to somebody else, however rarely anyone opens it. Microsoft gives deciding what is a record to "corporate compliance officers, records managers, and lawyers" (records management in SharePoint Server), and a farm refuses to delete a site collection "that's on hold" (eDiscovery and in-place holds, both checked on 6 November 2026). You record the obligation, its owner and its end; the project decides none of them.
Nobody owns it. Then the person who owns Chapter 6's ownership rule decides instead. We would write once to the listed owner and the secondary contact, with a date and the default that follows silence, and lock the site read-only from that date. SharePoint Server can automate the asking and delete what nobody confirms, but automatic deletion "permanently removes all the content and information" (manage unused site collections, checked on 6 November 2026). We would not let it take a migration's decisions.
A migration would copy it without improving it. Microsoft's migration guides ask whether content is "redundant, out of date, or still relevant" (team sites migration guide, checked on 6 November 2026). A copy of content kept elsewhere, a superseded site or a finished project's site arrives as it left, permissions and disorder included. The sharpest case is an application whose engine does not cross: Subscription Edition removed Access Services and PerformancePoint Services (what is deprecated or removed, checked on 6 November 2026), so a site built on them has nothing to run it there, and its data is decided as data, as Chapter 20 decides a form library's.
A site that meets none of the four migrates. Meeting one makes it a candidate, never a decision: low use opens the question, and only an owner's answer, or the recorded absence of one, closes it.
Four dispositions
| Disposition | It fits when | Needed first | What Microsoft documents |
|---|---|---|---|
| Migrate | People use it and someone owns it | A wave, a verification and a cutover | The attach (Chapter 23) or the copy (Chapters 8 and 9) |
| Archive | It must be kept or may be needed, and nobody works in it | The obligation and its end, from its owner; a way to find and recover content | Microsoft 365 Archive online; on a farm, a records archive or records managed in place |
| Keep read-only | It is read but no longer changed, or awaits its owner's answer | An end date, and what follows it | A read-only site lock, on both platforms |
| Delete | Nobody uses it, nothing requires it, and its owner agreed or nobody claimed it | A hold check, a backup with its own end date, a row in the deletion record | Remove-SPSite, after a backup |
The farm's two archive models come from records management in SharePoint Server (above); the other sources follow.
What each holding state does to the content
| Compared on | Read-only lock, SharePoint Server | Read-only lock, SharePoint Online | Microsoft 365 Archive |
|---|---|---|---|
| Set, and undone | Set-SPSite -LockState ReadOnly, then Unlock | Set-SPOSite -LockState ReadOnly, then Unlock | Set-SPOSiteArchiveState; reactivation is instant for seven days, then takes up to 24 hours |
| Users | Read; additions, updates and deletions return an error | Read, under a read-only notice | No direct access until an administrator reactivates the site; web search finds it under Archived, trimmed to each user's access |
| Retention | The farm's own holds and records management | Purview applies, but deletes nothing while the lock holds | Purview applies, deletions included, and eDiscovery finds the content |
| Limits | None stated | Not the root site | A supported template: not publishing, channel or some legacy sites; a hub is unregistered first |
Sources for the table: lock status on a farm and online; Microsoft 365 Archive overview, management and states; retention for SharePoint; all checked on 6 November 2026, and archive search, with the overview and management again for the limits, on 7 November 2026.
If an obligation ends in deletion, archive rather than lock. Online, under a ReadOnly or NoAccess lock, "items in that site can't be deleted" (retention for SharePoint, above), while an archived site still loses what its retention policies delete (management, above). Retention policies also skip list items, which only retention labels cover (same source), so an application kept for its list data needs labels.
Online, the lifecycle policies still reach a held site. The inactive site, site ownership and attestation policies keep in scope a read-only site locked "because of reasons other than site lifecycle management" (inactive site policy, checked on 7 November 2026), so a policy set to archive after its read-only period can archive a site this chapter kept read-only. Archiving a group-connected site archives the site alone, and "the rest of the group remains active" (management, above). Microsoft does not say whether the group expiration policy spares that group, and once an expired group is deleted its sites' data is permanently deleted 30 days later (group expiration, checked on 7 November 2026). We would take held sites out of those policies' scope, or have their records owner agree to what the policies do.
The farm's records controls do not cross online in a supported state. Microsoft's deprecation timeline for SharePoint in Microsoft 365, still marked approximate, ends support for the Records Center template in January 2025 and for information management policies, in-place records management and document deletion policies in April 2026, and Microsoft "won't automatically migrate" them (use Purview instead, checked on 6 November 2026). The obligation's owner rebuilds it in Purview before you copy the site, following Microsoft's migration strategies (checked on 6 November 2026). On Subscription Edition, Microsoft's records management guidance still applies (above).
Microsoft 365 Archive starts after a copy. It keeps data "in place in SharePoint" (archive FAQ, checked on 6 November 2026), and we do not know of a Microsoft path that archives farm content without copying it online first. The copy goes into a site whose template the archive supports, and Chapter 8 verifies it like any other, because an archive is evidence too.
The old farm keeps content read-only only until it goes. SharePoint Server 2016 and 2019 have been out of support since 14 July 2026 (ending support in 2026, checked on 6 November 2026), and Microsoft expects a farm of read-only databases to be part of a recovery, maintenance or upgrade environment (read-only databases, checked on 6 November 2026). We would keep content there only until the decommissioning date, locked ReadOnly, never NoAccess, for the reason Chapter 9 gives.
Delete only what you can account for
Remove-SPSite "completely deletes an existing site collection and all subsites" (Remove-SPSite), and Microsoft's procedure starts by making sure "a backup copy of the site collection and all of its contents exists" (delete and restore site collections, both checked on 6 November 2026). That backup is an archive nobody can search, so it gets its own end date. Detaching is not deleting: Dismount-SPContentDatabase "does not delete the content database from SQL Server" (attach or detach content databases, checked on 6 November 2026).
Each deletion leaves a row: the site, its size and item count, the evidence, the hold check, who agreed and when, and where the backup is and until when. The row sits beside the verification record that Chapter 9 archives before the source is decommissioned, and proves the site was removed on purpose. A site with no disposition holds that gate shut.
Out of scope
Measuring use across a farm is Chapter 14, archiving before the migration Chapter 27, modernising first Chapter 28, and tooling, including leaving files behind inside a migrating site, Chapter 29. File plans, retention schedules and Purview policies belong to the records owners, as Chapter 6 said. Decommissioning the farm itself is Chapter 38, and measuring what the project achieved Chapter 40. Pricing and licensing are not covered.
Before you continue
- Every site collection and application has one disposition: migrate, archive, keep read-only or delete
- Every "nobody uses it" names its source and its window, and no missing value was read as zero
- Every obligation has its owner and its end, and the project decided none of them
- Every ownerless site was written to with a date and a default, and locked read-only from that date
- Every site leaving an attach was deleted before the backup or moved to a database you do not attach
- Everything kept read-only has an end date and no policy acting on it unagreed, and retention that ends in deletion is archived, not locked
- Every deletion has a hold check, a backup with its own end date and a row in the deletion record
Download chapter 26 (PDF)Same text, same tables, same sources as this page.
Send us a message
or write to hello@ph7x.com
This chapter is free, and it stays free. If it saved you time, you can support the research and writing behind the Field Guide.
Buy me a coffee (opens in a new tab)João Lívio's page on buymeacoffee.com