Keep Subscription Edition supported, one update at a time

A farm built as Chapter 23 describes is supported on the day its last database attaches. A year later, nothing done in the migration decides whether it still is: Subscription Edition is serviced every month, and support follows the build the farm runs. The same holds for a farm built new; a 2016 or 2019 farm is past its end of support, as Chapter 7 records.

What does staying current require of this farm, and how does each public update reach production rehearsed, proved and with a way back?

The decision this chapter leads to is the update calendar the farm commits to: how soon after release each public update reaches production, where it is rehearsed first, and what the farm returns to if it fails.

Supported means current, and current has a date

Sources: the lifecycle page, additional support commitments, the Modern Lifecycle Policy and its FAQ, and the servicing policy, all checked on 6 November 2026.

On 6 November 2026, by Microsoft's update history and our arithmetic, the latest update is October's KB5002927 (16.0.20326.20190) and the oldest still supported is November 2025's KB5002800 (16.0.19127.20338), until 10 November 2026. From Version 24H2, Central Administration and the SharePoint Management Shell give notice six months before a build's end of support, warn at three, and show an error after it, the only one documented as reaching the Windows Application Event Log (Version 24H2, checked on 6 November 2026). A monthly calendar never sees the first notice; monitoring that reads only the log learns too late.

What arrives, and when

Public updates are cumulative, Microsoft plans no service packs, and "you can install any PU directly on an RTM installation, or on top of any previous PU" (servicing FAQ, checked on 6 November 2026). Feature updates come twice a year, in the spring and the autumn, inside a monthly update that every later one carries; October 2026's brought Version 26H2 (KB5002927, checked on 6 November 2026). The ring decides what switches on: Standard release, the default, is for farms "willing to wait longer for new feature experiences"; Early release is "supported for production use but may change"; a change of ring takes the Configuration Wizard on every server (feature release rings, checked on 6 November 2026). Standard waits; it does not refuse.

Every 2026 update came out on the second Tuesday of its month, but not every update waits for one: on 21 July 2025, KB5002768 replaced a security update thirteen days old, and its notes gained a known-issues section a week later (KB5002768, checked on 6 November 2026). Microsoft "recommends customers adopt security updates immediately", says the Modern policy.

Each update is two operations

The patch phase copies new binaries to every server; the build-to-build upgrade, psconfig on every server, "modifies database schemas, updates objects in the farm, and updates site collections". It can wait, though Microsoft warns that the longer it waits the likelier a problem, and an automatic update does only the first phase (software updates overview, checked on 6 November 2026). An update that Windows Update installed is half an update.

Microsoft documents installing in place, with or without backward compatibility, or onto a second farm by database attach (install a software update), and zero downtime patching for highly available farms (zero downtime patching), both checked on 6 November 2026. The choice decides the way back:

Microsoft's pages cited here describe no way to remove a public update. We do not know of a supported one, and would not plan a window around one.

Rehearse what production will get, from production's build

Microsoft's guidance is a test farm "that represents the production environment", on "a copy of the production data", timed end to end with backup and validation (software updates overview, checked on 6 November 2026). We would add two conditions: it starts from production's build, in production's ring.

The build matters because exceptions arrive in the notes, not in the policy. A farm on the January 2026 update that goes straight to March fails in psconfig, say the March notes, which ask for February first, with psconfig after each (KB5002843, checked on 6 November 2026). They name that one starting point. For others we do not know, and the rehearsal is what finds out.

The notes also say what to test. In 2026:

All three checked on 6 November 2026. Read the notes at release and again before the window, because they change.

A feature update can change a default the farm relies on. Version 26H2 put "AMSI Body Scan Defaults to “Full Mode”" in Standard release (Version 26H2), while the AMSI page still gives Balanced as the default body scan, and says that since the September 2025 public update AMSI "is a mandatory component and can no longer be deactivated" (AMSI integration, both checked on 7 November 2026). Neither page says whether a web application already set to Balanced is moved, so the rehearsal reads each web application's AMSIBodyScanMode (0 Off, 1 Balanced, 2 Full) before and after the update.

Prove it on every server

Once psconfig has finished everywhere, run this on each server:

# Read-only. Lists this server's SharePoint products and the update version of each.
Write-Host "Reading installed products and updates on $env:COMPUTERNAME"
Get-SPProduct -Local

Get-SPProduct returns "the versions of all updates installed for each product". A server reading anything but "No action required" on the Upgrade and Migration page has not finished (software updates overview); the Upgrade Status page lists each session's errors and warnings, and Microsoft's checks of service applications, site features and search follow (verify database upgrades), all checked on 6 November 2026. Then run the notes' tests, and record the build, the date, the duration against the rehearsal's, and who signed.

The calendar the farm commits to

Microsoft recommends installing updates "as soon as they become available" (servicing FAQ, checked on 6 November 2026). We recommend committing to the month: each update in production before the next is released. The farm is then never more than one update behind, and a failed update leaves it on a build with about ten months of support. Slower calendars stay supported until they slip.

Plan to the month; the year is the margin.

We would keep it to one update at a time: one per window and nothing else in it, so that a failed night has one suspect. A change of ring, Windows Server or SQL Server gets a window of its own, a feature update a longer rehearsal, and a security update released between months the same steps in days.

Out of scope

The upgrade itself is Chapter 23. Left out: choosing the ring, which our comparison of the editions covers; backup and recovery design; high availability; Windows Server, SQL Server and Workflow Manager updates; and Project Server Subscription Edition, whose earliest end of support on the same list is 31 December 2031.

Before you continue

• Each server's update is recorded and dated, with the day its build leaves support
• The calendar fixes the lag to production, and a faster lane for security updates
• Each update's notes are read at release and again before the window
• Each update is rehearsed and timed on a test farm at production's build and ring, its AMSI body scan mode read before and after
• The way back is checked before the window: a backup, a whole-farm image or a second farm
• After psconfig everywhere, versions, upgrade status and checks are recorded and signed
• A change of ring, Windows Server or SQL Server gets a window of its own

Download chapter 42 (PDF)Same text, same tables, same sources as this page.