SharePoint 2016 and 2019: No ESU, and No Staying Put

Extended support for SharePoint Server 2016 and 2019 ended on 14 July 2026. Nothing stopped. Your farm serves pages today exactly as it did on the 13th, which is the part that lets a farm sit unpatched for a year while everyone agrees it is a priority.

That same date ended extended support for SQL Server 2016, and comparing the two is the fastest way to see what you actually have here.

There is no bridge to buy

Extended Security Updates are a real program with real prices, and SharePoint is not in it. Microsoft’s ESU documentation covers SQL Server 2014 and 2016; Windows Server has its own. SharePoint Server has neither. When Microsoft stopped patching on 14 July, that was the end of the line, with no paid extension at any price.

This changes what “we need more time” means. On the SQL Server side, more time is a line item: connect to Azure Arc, subscribe, pay by the core-hour, cancel when you land. On the SharePoint side, more time is just exposure. The only thing you can do with it is reduce what an unpatched farm can reach, which is worth doing and is not a solution.

If you are running both, and many organizations are running SharePoint on SQL Server 2016 because the requirements have accepted anything from SQL Server 2012 onward, then two clocks stopped under the same farm on the same day. The database one you can pay to restart. The details of that are worth reading separately, because the retroactive billing means waiting costs money without buying coverage.

Subscription Edition is not “staying where we are”

The framing in most write-ups is cloud versus on-premises: move to SharePoint Online, or stay on-premises with Subscription Edition. That framing is wrong about what SPSE costs you, in two specific ways.

There is no in-place upgrade. Microsoft documents one method, database attach. You build a complete SPSE farm on new servers, set the old farm read-only, back up the content and service application databases, restore them onto the new farm, and attach and upgrade them there. Then you recreate every web application, reinstall every server-side customization, and upgrade the site collections. Five service application databases carry across: Business Data Connectivity, Managed Metadata, Search, Secure Store, and User Profile. Anything else is rebuilt.

That is a farm migration with a content copy in the middle. It is the same class of project as moving to SharePoint Online, not a smaller one.

The license is a subscription wearing different clothes. SPSE is not sold as a perpetual license. It is available through Software Assurance, and when Software Assurance lapses the right to run it lapses with it. So an organization choosing SPSE to avoid a per-user cloud subscription has chosen a per-server subscription plus the servers, the SQL Server licensing, the backup and disaster recovery infrastructure, and the staff time to patch all of it.

Audit the Software Assurance status before you commit to that path, not after. Farms that have been running quietly for years are exactly the ones where SA lapsed at some renewal nobody was watching, and the gap between renewing and buying cloud licenses is often smaller than people assume once both are quoted.

The gate that will stop you on the day

One number decides whether the migration can start at all: all databases must be at build 16.0.4351.1000 or higher, or the upgrade to SPSE is blocked.

Check it now rather than during the cutover window:

Get-SPDatabase | Select-Object Name, Type, @{n='Build';e={$_.BuildVersion}} |
  Sort-Object Build

A farm that has been patched on schedule clears this without thinking about it. A farm that stopped getting cumulative updates somewhere around 2021, which is a common shape for the farms this deadline catches, has to be patched forward first. You end up applying updates to an unsupported product in order to earn the right to leave it, and that work has to finish before the migration project starts rather than in parallel with it.

Choosing between SPSE and SharePoint Online

The reasons to stay on-premises are narrow and specific. Data residency that no Microsoft 365 region or sovereign cloud offering satisfies. Air-gapped or classified environments. Full-trust farm solutions whose rewrite cost genuinely exceeds the cost of running a farm. Each of those is a named constraint someone can point at.

“We have always run our own servers” is not one of them, and neither is “we are not sure yet.” Hybrid in particular tends to be the option organizations back into rather than choose. It works, and it means maintaining a farm and a tenant at once, with search, permissions, and site structure stitched between them. Take it only when something specific has to stay.

I would not put a dollar figure on the comparison here, because the honest answer depends on things I cannot see: how many servers, which SQL Server edition, what your SA position actually is, and how much custom code is in the farm. Ask a reseller to quote both paths side by side. The point of this section is narrower, that SPSE is not the cheap default it looks like on a license comparison, because the migration work is comparable and the recurring cost does not go away.

Where these migrations actually break

The database move is rarely the hard part. Four things are.

InfoPath forms and SharePoint Designer workflows have no clean equivalent in SharePoint Online. Power Automate and Power Apps are the replacements, and that is a rebuild with its own requirements gathering, not a migration step. Full-trust farm solutions do not run in SharePoint Online’s model at all, and custom code written a decade ago by people who have left is worth finding and assessing before migration day.

Then there is permission drift. Years of individual “just give this person access” decisions accumulate into a structure nobody fully understands, and migration is when that comes due. Copying the mess into the new environment is possible and is how you carry a decade of accidental over-sharing into a tenant with more permissive default external sharing than your farm had. Remediating broken inheritance and orphaned permissions is part of the project, not a follow-up.

Content types and managed metadata are the fourth, and they are the reason to run an inventory before choosing tooling. Microsoft’s free options are SPMT for smaller, self-contained moves and Migration Manager, which is agent-based with scheduling and central reporting, for a farm’s worth of content. Paid tools such as ShareGate and AvePoint earn their cost when permissions need remapping rather than flattening, or when metadata needs transformation. Which of those you need is an output of the assessment, not an input.

The single largest lever on the timeline is not the tool. It is how much you refuse to move. Most farms of this age are substantially stale, old project sites, duplicate libraries, team sites abandoned three reorganizations ago. Archiving that instead of migrating it shrinks every subsequent step.

While the farm is still running

If the migration will not be finished for months, and for most farms it will not, treat the old farm as what it now is: a well-understood target running software with no vendor fixes coming. Restrict network access to the minimum that keeps it useful, and get it off the public internet if there is any way to do that. Raise monitoring and log review on that farm specifically rather than leaving it at whatever level made sense when it was patched.

None of that substitutes for the migration. It changes what an unpatched month costs, which is the only variable you control until the new farm exists.

Run the build-version check first. It takes a minute, it tells you whether the migration can start at all, and the answer determines whether your first task is planning or patching.