When do SharePoint Server 2016 and 2019 reach end of life?

Both reached end of extended support on July 14, 2026 — Microsoft aligned SharePoint Server 2019's end date with 2016's. SharePoint 2016 mainstream support ended July 13, 2021; SharePoint 2019 mainstream ended January 9, 2024. Unlike Exchange Server — which has a short paid ESU bridge ending October 2026 — SharePoint Server has no Extended Security Updates (ESU) program at all: there is no purchasable path to another security update. Microsoft did nonetheless release an August 11, 2026 security update for both versions (KB5002905/KB5002906 for 2016, KB5002894/KB5002896 for 2019) that fixed 27 CVEs across the two versions' packages, one of which Microsoft and CISA flagged as exploited on September 25, 2026; the September 2026 release carried none for either version. Nothing commits Microsoft to another one.

Is there an actively exploited SharePoint vulnerability in 2026?

Four as of September 2026. On July 14, 2026 — the same day SharePoint 2016 and 2019 reached end of support — Microsoft disclosed three vulnerabilities together and fixed all three that same day, for every affected version including 2016 and 2019: CVE-2026-56164, an elevation-of-privilege flaw caused by missing authentication for a critical function (CWE-306), which Microsoft describes as letting an unauthorized attacker elevate privileges over a network; CVE-2026-50522, a deserialization bug that Microsoft describes as allowing an unauthorized attacker to execute code over a network, at CVSS 9.8 — though Microsoft's own FAQ for that CVE describes exploitation as requiring an attacker already authenticated as at least a Site Owner, which sits oddly next to the CVSS vector's 'no privileges required'; and CVE-2026-55040, an authentication bypass in on-premises SharePoint Server's JWT token validation that Rapid7 and Microsoft disclosed jointly, with Rapid7's technical analysis following on August 11, 2026. CVE-2026-56164 was added to CISA's Known Exploited Vulnerabilities catalog first, on July 14, 2026, the day it was disclosed, and Microsoft's own record marks it exploited; CVE-2026-50522 followed on July 22, 2026, and CVE-2026-55040 on August 18, 2026. The fourth is CVE-2026-65660, a code-injection flaw that Microsoft's FAQ says requires 'an authenticated attacker with low-level access to an affected server.' Microsoft fixed it on August 11, 2026, then revised the advisory on September 25, 2026 to say it had reliable evidence of active exploitation — CISA added it to the KEV catalog that same day.

What is CVE-2026-55040?

CVE-2026-55040 is an authentication bypass in the JWT token validation of on-premises SharePoint Server. Rapid7 and Microsoft disclosed it jointly on July 14, 2026, the day the fix shipped. Rapid7 published its technical analysis on August 11, 2026, describing the impact as a remote, unauthenticated attacker bypassing authentication on a vulnerable SharePoint server and then performing operations as a SharePoint site user or administrator. CISA added it to the Known Exploited Vulnerabilities catalog on August 18, 2026, which is the point at which there is evidence of exploitation in the wild. One thing not to misread: the remediation due date attached to a KEV entry comes from Binding Operational Directive 26-04 and binds Federal Civilian Executive Branch agencies. It is not a legal deadline for a private company, and a short window is the catalog's normal shape rather than a severity signal. Check your own farm's patch state against Microsoft's advisory for the CVE, not against a version list in an article.

What can an out-of-support SharePoint farm actually do about a vulnerability like CVE-2026-55040?

Less than you would like, and that gap is the argument for migrating rather than a reason to despair. SharePoint Server 2016 and 2019 reached end of extended support on July 14, 2026 and have no Extended Security Updates program at any price — no purchasable bridge the way Exchange or SQL Server has. Microsoft did release one further security update for these versions after that date (August 11, 2026, which fixed CVE-2026-65660 among 27 CVEs for 2016 and 2019; the September 2026 release carried none), but nothing commits Microsoft to doing that again for the next one. Until the farm is migrated, everything else available is a compensating control: take the farm off the public internet, put authentication in front of it with a VPN or an authenticating reverse proxy, restrict and review farm-administrator access, monitor authentication logs for the anomalies you would look for after a compromise, and confirm your backups actually restore. Those measures reduce reachability and shorten dwell time. None of them substitutes for a patch, and all of them are stopgaps for a migration that still has to happen.

Did Microsoft release a security update for SharePoint Server 2016 or 2019 after end of support?

Yes, once so far. On August 11, 2026, four weeks after end of support, Microsoft released KB5002905 and KB5002906 for SharePoint Server 2016 and KB5002894 and KB5002896 for SharePoint Server 2019, fixing 27 CVEs across the two versions' packages, including CVE-2026-65660, which Microsoft and CISA flagged as exploited on September 25, 2026. The September 2026 release carried none for either version, and nothing commits Microsoft to another. It does not create an ESU program; the migration argument is unchanged.

What else reached end of support on July 14, 2026?

More than SharePoint, which is why the migration scope is usually bigger than teams expect. Microsoft's 2026 end-of-support list puts SharePoint Server 2016, SharePoint Server 2019, Project Server 2016, Project Server 2019, SharePoint Designer 2013, InfoPath 2013, SQL Server 2016, and SQL Server 2014 Extended Security Updates Year 2 all on the same date. If your SharePoint farm sits on SQL Server 2016, both tiers of that stack went out of support the same day. SQL Server 2016 at least has a paid three-year ESU ladder that began July 15, 2026; SharePoint has nothing equivalent at any price.

What are the migration paths from SharePoint Server 2019?

Three real paths: (1) full migration to SharePoint Online — the right answer for most organizations; (2) in-place upgrade to SharePoint Server Subscription Edition (SE) for organizations with regulatory data-sovereignty requirements; (3) selective hybrid — keep SharePoint 2019 for specific workloads with hard customizations or LOB integrations and move the rest to SPO.

How long does a SharePoint 2019 to SharePoint Online migration take?

For 50 users, 60–90 days end-to-end. For 200 users, 90–150 days. For 500 users, 150–240 days. The dominant variable is custom code and third-party solution dependencies — every InfoPath form, every farm-solution WSP, every workflow that doesn't translate cleanly to Power Automate adds time.

What does SharePoint Server Subscription Edition cost compared to SharePoint Online?

SharePoint SE is licensed per server plus per user CAL on a subscription model. For most mid-market environments, the three-year TCO of SharePoint SE — including hardware refresh, Windows Server licensing, SQL Server, backup, patching labor, and Microsoft 365 plans you're already paying for — runs 2–3x the SharePoint Online line item already included in most M365 plans. SE is the right answer when data sovereignty mandates it, not when it's cheaper, because it usually isn't.

Blog · 16 min read · May 20, 2026

SharePoint 2016 & 2019 EOL July 14, 2026: three paths

SharePoint Server 2016 and 2019 reached end of extended support July 14, 2026 — the deadline is now PAST. There is no ESU program for SharePoint at any price, though Microsoft did ship one further security update for these versions on August 11, 2026. Four actively-exploited vulnerabilities have hit this stack: CVE-2026-56164 (privilege escalation, fixed July 14, 2026), CVE-2026-50522 (CVSS 9.8 remote code execution, fixed July 14, 2026), CVE-2026-55040 (authentication bypass, fixed July 14, 2026 and added to CISA's Known Exploited Vulnerabilities catalog on August 18), and CVE-2026-65660 (CVSS 8.8 code execution requiring low-privilege authentication, fixed August 11, 2026, added to KEV September 25 after Microsoft found evidence of active exploitation). Unmigrated farms have no committed fix for the next one.

Update — September 26, 2026: a fourth actively-exploited flaw, and it's already fixed if you patched. CVE-2026-65660 is a code-injection vulnerability in SharePoint Server. Microsoft's FAQ describes how it's exploited in plain terms: "An authenticated attacker with low-level access to an affected server could send a specially crafted request to execute code on the server. User interaction is not required." It scores CVSS 8.8 — network reach, low complexity, low privileges required, no user interaction.

Microsoft published the advisory on August 11, 2026, the same day it shipped the fix, and revised it twice since: an informational-only update on August 27, then, on September 25, 2026, a substantive one — "As of 9/25/2026, Microsoft had reliable evidence of observed attacks against exploitation of this vulnerability." CISA added the CVE to the Known Exploited Vulnerabilities catalog that same day, September 25.

Read the revision history, not the static flag. MSRC's own exploitability field for this CVE still read "Exploited: No" when we checked on September 26, 2026. What moved is the revision history and the KEV listing, both dated September 25. Trust those two over the flag.

The fix already shipped, six weeks before Microsoft reported exploitation. The August 11, 2026 update carries it: KB5002905 and KB5002906 for SharePoint Server 2016 (build 16.0.5565.1001), KB5002894 and KB5002896 for SharePoint Server 2019 (build 16.0.10417.20198), and KB5002893 for Subscription Edition (build 16.0.19725.20522). If your 2016 or 2019 farm hasn't installed it, install it — and the July 14, 2026 update too, if that is also missing. It does not change the migration argument below: 2016 and 2019 are still past end of extended support with no ESU program, this update doesn't extend that, and nothing commits Microsoft to shipping another one.

⚠️ Same caveat as the entries below: the KEV remediation-due date binds Federal Civilian Executive Branch agencies under Binding Operational Directive 26-04. It is not a deadline for a private company.

Update — August 19, 2026: the exploit cycle is now shorter than a patch policy. CVE-2026-55040 is an authentication bypass in the JWT token validation of on-premises SharePoint Server. Rapid7 and Microsoft disclosed it jointly on July 14, 2026 — the same day SharePoint 2016 and 2019 went out of support — and Rapid7's public technical analysis followed on August 11. On August 18, CISA added it to the Known Exploited Vulnerabilities catalog. Rapid7's description of the impact is plain: a remote, unauthenticated attacker can bypass authentication on a vulnerable SharePoint server and then operate as a SharePoint site user or administrator.

The dates are the argument, not the CVE. Twenty-eight days from patch to public technical analysis. Seven more to a federal catalog entry that exists only where there is evidence of exploitation in the wild. Set your own remediation policy next to that sequence: if critical fixes get a 30-day SLA, the policy is now longer than the window between the patch shipping and the flaw being used. A compliant, on-time patch cycle can still leave you exposed for the part of the month that matters — and that is the good case, the one where a patch exists at all.

Which is the whole point of this post. An out-of-support SharePoint 2016 or 2019 farm has no committed patch to be late with. (Corrected September 26, 2026: Microsoft did ship one more update for these versions on August 11, 2026 — see the September 26 update above — but nothing commits it to another.) Every argument below about migration timelines is really an argument about how many of these cycles you intend to sit through without a committed fix.

⚠️ One thing not to repeat: the three-day remediation due date on that KEV entry does not bind you. It comes from Binding Operational Directive 26-04, which applies to federal civilian agencies, and a three-day window is the catalog's norm rather than a severity signal. The listing itself is the signal. We cover that distinction, and the triage you run after patching, in CISA KEV in 2026: patch, then assume compromise.

Update — August 3, 2026: a second exploited SharePoint flaw, and this one is worse. (56164 fix status corrected September 26, 2026 — see below.) CVE-2026-50522 is a deserialization bug that, in NVD's words, "allows an unauthorized attacker to execute code over a network." It scores CVSS 9.8 Critical — network reach, low complexity, no privileges, no user interaction — and CISA added it to the Known Exploited Vulnerabilities catalog on July 22, 2026. That is the second actively-exploited SharePoint vulnerability in a month, and it is a full remote-code-execution flaw rather than a privilege-escalation one.

Read the patch status carefully, because the nuance is the whole point. NVD lists fixed builds for 2016 (16.0.5561.1001), 2019 (16.0.10417.20175), and Subscription Edition (16.0.19725.20434) — the July elevation-of-privilege flaw described below shipped fixed builds the same day, for the same versions. Apply both. But understand what you are holding: both versions are now out of support with no ESU program, so there is no commitment that a fix will exist for the next one. The exposure is not this CVE. It is the one after it.

Also from July 2026: CVE-2026-56164, an elevation-of-privilege flaw (missing authentication, CWE-306) that Microsoft describes as letting an unauthorized attacker elevate privileges over a network. Microsoft confirms active exploitation and CISA listed it the same day it was disclosed, July 14. Its affected-products list includes 2016, 2019 and Subscription Edition — and a fix shipped for all three that day: the same KBs that fix CVE-2026-50522 above (5002891 for 2016, 5002883 for 2019, 5002882 for Subscription Edition) carry the fix for this one too. That is still two actively-exploited SharePoint vulnerabilities disclosed in the same month, both patched the same day the older versions' support ended — see the September 26 update above for the fourth.

If your organization is still running SharePoint Server 2016 or 2019, the runway is gone: both versions reached end of extended support on July 14, 2026. (SharePoint 2016 mainstream support ended July 13, 2021; SharePoint 2019 mainstream ended January 9, 2024 — Microsoft aligned 2019's extended-support end date to 2016's.) There is no Extended Security Updates program for SharePoint Server. Exchange Server has a short paid ESU bridge that ends in October 2026; SharePoint has nothing of the kind. There is no program guaranteeing your farm another security update — Microsoft did release one further security update for these versions on August 11, 2026 (the September 2026 release carried none), but nothing commits it to doing that again — and, as CVE-2026-56164 above shows, "no committed update" is not a slow problem. The goal now is a committed, scoped migration path with the security gap measured in weeks, not quarters.

Past the deadline — now what? A SharePoint Online migration for a 200-user farm runs 90–150 days end-to-end, so most organizations still on 2016/2019 cannot "catch up" instantly. The realistic goal is to get onto a committed, scoped path immediately and shrink the unsupported window — while treating the farm as actively at risk in the meantime (network-isolate where you can, watch it closely, and confirm the farm has every fix below installed: the July 14, 2026 update that covers CVE-2026-50522, CVE-2026-55040, and CVE-2026-56164, and the August 11, 2026 update that covers CVE-2026-65660). The one option you do not have is "wait for ESU," because there isn't one.

There are exactly three real paths from here. This post walks each one with realistic timelines for 50-, 200-, and 500-user environments, the costs that actually show up in the budget, and the most common ways each path fails. It mirrors the format of our Exchange 2019 EOL post deliberately — the EOL decision tree is similar in shape, different in detail.

Where we actually are right now

Milestone	Date	What it means
SharePoint Server 2016 mainstream EOS	`Jul 13, 2021`	No more feature updates. Security updates only since this date.
SharePoint Server 2019 mainstream EOS	`Jan 9, 2024`	No more feature updates. Security updates only since this date.
SharePoint Server SE released	`Nov 2021`	Subscription Edition. In-place upgrade path from 2019 (2016 upgrades via 2019 first).
SharePoint 2016 and 2019 extended support ends	`Jul 14, 2026`	Hard deadline for both versions. No ESU program — no purchasable path to a future update, though Microsoft did release one further security update on August 11, 2026.

The contrast with Exchange Server is important: Exchange 2019 customers get a paid ESU bridge through October 2026. SharePoint 2019 customers do not. Your runway is shorter, and the "buy time with ESU" option that exists for Exchange does not exist for SharePoint.

Quotable stat: SharePoint Server 2019 has no Extended Security Updates program. Unlike Exchange Server, Windows Server, and SQL Server — all of which offer ESU bridges past extended support — SharePoint Server EOL was a hard deadline: no purchasable path to another security update, at any price. Microsoft still shipped one anyway on August 11, 2026, fixing 27 CVEs for 2016 and 2019 — but that was Microsoft's own call, not a program you can buy into, and the September 2026 release carried none for either version.

Path 1: SharePoint Online — the right answer for most

Migrate every site collection, every document library, and every list to SharePoint Online. Reconfigure shared storage on OneDrive for Business with Known Folder Move (KFM). Decom the on-prem SharePoint farm — including SQL backends, search index, and any custom WFE servers.

This is the right answer for most organizations. The license you're already paying for in your Microsoft 365 plan covers SharePoint Online and OneDrive for Business. The operational cost of running an on-prem SharePoint farm — patching, SQL backup, search index health, custom solution maintenance, the tribal knowledge that lives in one engineer's head — is a tax you can stop paying.

Tooling: ShareGate vs Mover.io vs native

Three real options, each landing in a different scenario:

ShareGate Migrate — the mid-market and enterprise default. Strongest at preserving permissions, version history, customizations, and metadata across complex source farms. Per-user licensing with a tiered structure. The right answer when fidelity matters and when the source farm has any meaningful customization.
Mover.io (now part of Microsoft 365 Migration) — Microsoft's built-in tool, free with M365, strongest at file-share to OneDrive/SharePoint Online migrations. It is not the right tool for complex SharePoint-to-SharePoint moves with custom workflows and metadata. Good for the file-share leg of a hybrid project; not the SharePoint farm itself.
SharePoint Migration Tool (SPMT) — native — Microsoft's free SharePoint-specific tool. Adequate for simple migrations with minimal customization. Falls down on complex permission inheritance, InfoPath forms, and farm-solution WSPs.

Vendor-neutral framing: ShareGate is what we reach for on most mid-market engagements where source-farm customization is non-trivial. SPMT is the right call when the source farm is a near-vanilla 2019 install with minimal custom code. Mover.io owns the file-share leg. We don't resell any of them.

Realistic timelines

Environment	Discovery	Pilot	Cutover	Hypercare	Total
50 users, ~5 site collections	1 wk	2 wks	4–8 wks	1 wk	~60–90 days
200 users, ~25 site collections	2 wks	3 wks	8–14 wks	2 wks	~90–150 days
500 users, ~75 site collections	3 wks	4 wks	12–24 wks	2 wks	~150–240 days

Add 4–10 weeks if the source environment includes InfoPath forms (no automatic translation; rebuild as Power Apps), SharePoint Designer workflows (rebuild as Power Automate), or farm-solution WSPs (rebuild as SPFx). The customization tail is the dominant scheduling variable on most SharePoint migrations we've run.

File-share migration patterns: If your SharePoint 2019 environment also fronts older file shares — and most do — the file-share leg is its own sub-project. The pattern that works: target SharePoint document libraries for collaborative content, OneDrive with Known Folder Move for personal/desktop content, Azure Files SMB only for legacy-app dependency cases that can't move to SharePoint. Mixing these incorrectly is the most common mid-cutover slowdown.

Where Path 1 fails: teams under-scope the customization rebuild. InfoPath, Designer workflows, and farm solutions all need to be inventoried in week 1, not discovered in week 9. Permission inheritance on long-lived sites is also commonly a surprise — the source environment has 12+ years of accumulated inheritance breaks and explicit permissions that need rationalization before they get carried into SPO.

Path 2: SharePoint Server Subscription Edition

Microsoft released SharePoint Server Subscription Edition (SE) in November 2021. It's the on-prem continuation path — same deployment model, modern auth, subscription licensing instead of perpetual. In-place upgrade is supported from SharePoint Server 2019 with the most recent CU level.

Why might you choose this? You have a real reason to keep SharePoint on-premises:

CMMC Level 3 or other US defense data-handling requirements that mandate on-prem or sovereign-cloud workloads
Regulated financial services with jurisdictional rules requiring on-prem document storage
EU data residency mandates that aren't satisfied by Microsoft 365's EU Data Boundary for the specific data class in scope
Air-gapped or sovereign-cloud environments where SharePoint Online is not an option

Outside those scenarios, SharePoint SE is rarely the right answer despite being the on-prem continuation. The license-plus-hardware-plus-operations math almost always loses to SharePoint Online once you account for what's already included in the M365 plans you're paying for. We've watched several mid-market customers commit to SE because "we already have the team for it" and regret it 18 months later when the SQL upgrade, the hardware refresh, and the SE CU cycle all hit at once.

What the upgrade actually requires

SharePoint Server 2019 must be on the most recent CU. If you're behind, plan for the CU sequence first.
Hardware refresh. SharePoint SE's published hardware requirements are higher than 2019. If your farm is on hardware that's been live since 2019, plan for replacement.
SQL Server upgrade. SharePoint SE supports newer SQL versions. Plan the SQL upgrade as a parallel project.
Modern auth integration. SharePoint SE supports modern authentication via OIDC. If your farm is on classic auth (NTLM/Kerberos only), the upgrade is also a modernization.
Custom solutions audit. Farm-solution WSPs may not be supported in SE the same way. Audit each one against the SE supportability matrix before the upgrade.

Realistic timeline: 8–16 weeks for the upgrade itself, assuming hardware is procured and SQL is in a known state. Plan for Cumulative Updates every 6–8 months indefinitely. This is a real ongoing commitment, not a one-time project.

Reality check: if you're considering SharePoint SE because "we've always done it this way," that's inertia, not a reason. Run the three-year TCO honestly. Hardware + Windows Server CALs + SQL Server + backup + patching labor + the M365 plan you're already paying for is almost always more expensive than just moving to SharePoint Online. The data-sovereignty cases above are real; the inertia case is not.

Path 3: SharePoint hybrid + selective workloads

Keep SharePoint Server 2019 (upgraded to SE for security continuity) for specific workloads — heavy customizations, LOB applications with hard SharePoint integration, or content classes that genuinely cannot move to SPO. Migrate the rest to SharePoint Online. Run the two in a hybrid configuration with SharePoint hybrid search and federated navigation.

This is the most complex path. It is the right answer in a narrow set of scenarios:

Specific LOB apps that integrate via SharePoint server APIs (full-trust solutions, server object model dependencies) and have no migration roadmap to SPO
Content classes that the business explicitly cannot move to SPO (regulated, sovereignty-constrained) where the rest of the environment is moving
Phased migrations where the on-prem retention is a transition state, not a permanent endpoint

What hybrid actually means in practice

An on-prem SharePoint Server SE farm running the workloads that stay on-prem
SharePoint Online for everything that moved
SharePoint hybrid configuration providing federated search across both, hybrid OneDrive redirection, and hybrid extranet sites if needed
Entra Connect with synchronized identities (already in place for most M365 customers)

Hybrid is a long-term operational commitment. You're running both farms — patching both, monitoring both, integrating both — and you're carrying the customization tail of the on-prem environment indefinitely. It's the right answer when the cost of forcing migration of the held-back workloads exceeds the cost of running hybrid. It is rarely the right answer when the held-back workloads could be modernized given two more quarters of rebuild work.

Where Path 3 fails: the held-back workloads were always going to be migrated eventually, and the hybrid posture extends the project's runway by years rather than months. If "selective hybrid" becomes "permanent hybrid because nobody got around to finishing the migration," you're paying for two environments forever. Set a sunset date for the on-prem remainder when you scope Path 3, not when the hybrid posture has been live for three years.

SharePoint 2019 End of Support: It Already HappenedWatch on YouTube (opens in a new tab)

The decision tree, simplified

Your situation	Right path
Most users, no regulatory constraint blocking cloud	Path 1 (full SharePoint Online migration)
CMMC L3 / sovereign-cloud / regulatory mandate to keep on-prem	Path 2 (SharePoint SE)
Heavy custom WSPs or LOB integrations + cloud-blocked subset	Path 3 (selective hybrid, with sunset date)
"We have time" / "We'll figure it out next year"	You don't have time. ESU does not exist for SharePoint.

What we recommend doing this week

Inventory. Confirm SharePoint version and CU, site-collection count, document and list counts, customization footprint (InfoPath forms, Designer workflows, farm-solution WSPs, SPFx solutions), third-party integrations, and storage footprint per site collection. Most environments don't have an accurate inventory and that's the source of every blown SharePoint migration.
Decision committee. IT director, CIO, security/compliance, and any LOB application owner with a SharePoint-server dependency. Walk the three paths. Commit to one with a sunset date for any retained on-prem footprint.
Engage scope. Whether the work is in-house or with a consultancy, get a written scope on paper with a timeline, a budget, and acceptance criteria. The total fixed-fee labor for Path 1 ranges from $20K (50 users) to $80K (500 users) depending on customization tail.

Common mistakes we see right now

Treating the customization tail as a "we'll figure it out" item

InfoPath forms, SharePoint Designer workflows, and farm-solution WSPs do not migrate themselves. The decision isn't "do we move them" — it's "do we rebuild them, retire them, or keep them on-prem." That decision needs to happen in week 1, with the business owner of each customization in the room.

Skipping the file-share story

Most SharePoint 2019 environments also front older file shares. The file-share migration is its own project with its own tooling and its own change-management overhead. Bake it into the SharePoint scope or run it as a parallel track — but don't pretend it's a side conversation.

Buying SharePoint SE because it feels safer

On-prem SharePoint feels safer to teams who've operated SharePoint farms for a decade. The three-year TCO math almost never agrees with that feeling. SharePoint SE is the right answer when sovereignty mandates it, not when it's emotionally familiar.

Treating July 14, 2026 as "extended support" the way Exchange does

There is no SharePoint ESU program. The deadline is hard. If your "plan" is "we'll buy ESU like we did with Exchange," there is no ESU to buy. Re-plan accordingly.

One more thing: SharePoint wasn't the only product that died that day

Scoping conversations tend to start and end with SharePoint, and then the project plan grows in week three. Microsoft's 2026 end-of-support list puts all of the following on July 14, 2026 — the same date:

SharePoint Server 2016 and SharePoint Server 2019
Project Server 2016 and Project Server 2019 — these ride on SharePoint, and teams routinely forget they are separate products with their own support dates
SQL Server 2016 — very often the database tier underneath the farm you are migrating
SQL Server 2014, Extended Security Updates Year 2
SharePoint Designer 2013 and InfoPath 2013 — still load-bearing in more mid-market workflows than anyone likes to admit

The practical consequence: if your SharePoint farm runs on SQL Server 2016, both tiers went out of support on the same day, and they do not have the same escape route. SQL Server 2016 has a paid Extended Security Updates ladder that started July 15, 2026 and runs in three annual steps to July 2029 — and note that it is genuinely paid. Microsoft states that starting with SQL Server 2016, moving a workload to SQL Server on Azure VMs no longer provides free access to ESUs; that concession applies to SQL Server 2014, not 2016. SharePoint Server has no ESU program at any price. So the database can be bought time, at a price; the farm cannot be bought time at all. We covered what those ESUs actually cover, what they cost, and the four remaining paths in SQL Server 2016 end of support: ESU or upgrade?. Scope both tiers before you commit to a date, and check whether InfoPath forms or SharePoint Designer workflows are quietly in the critical path — those are the two that turn a clean migration into a rebuild.

Sources and further reading

The 30-second version

SharePoint Server 2016 and 2019 both reached end of support on July 14, 2026 — that date has passed. There is no ESU program for SharePoint at any price. Three real paths: SharePoint Online for most, SharePoint SE for sovereignty-constrained workloads, selective hybrid only with a written sunset date. The customization tail (InfoPath, Designer workflows, farm-solution WSPs) is the dominant scheduling variable. Inventory this week, decide next week, scope by end of month.

If you'd like a senior engineer to walk through it with you, the project intake form takes about three minutes. We'll come back with scope and a fixed-fee range.

Pro IT NW does senior-led Microsoft project work. Vendor-neutral. Labor-only. Based in Seattle, delivered USA-wide. We don't take resale margins on SharePoint, ShareGate, or any of the destinations in this post.

Questions we get asked

When do SharePoint Server 2016 and 2019 reach end of life?: Both reached end of extended support on July 14, 2026 — Microsoft aligned SharePoint Server 2019's end date with 2016's. SharePoint 2016 mainstream support ended July 13, 2021; SharePoint 2019 mainstream ended January 9, 2024. Unlike Exchange Server — which has a short paid ESU bridge ending October 2026 — SharePoint Server has no Extended Security Updates (ESU) program at all: there is no purchasable path to another security update. Microsoft did nonetheless release an August 11, 2026 security update for both versions (KB5002905/KB5002906 for 2016, KB5002894/KB5002896 for 2019) that fixed 27 CVEs across the two versions' packages, one of which Microsoft and CISA flagged as exploited on September 25, 2026; the September 2026 release carried none for either version. Nothing commits Microsoft to another one.
Is there an actively exploited SharePoint vulnerability in 2026?: Four as of September 2026. On July 14, 2026 — the same day SharePoint 2016 and 2019 reached end of support — Microsoft disclosed three vulnerabilities together and fixed all three that same day, for every affected version including 2016 and 2019: CVE-2026-56164, an elevation-of-privilege flaw caused by missing authentication for a critical function (CWE-306), which Microsoft describes as letting an unauthorized attacker elevate privileges over a network; CVE-2026-50522, a deserialization bug that Microsoft describes as allowing an unauthorized attacker to execute code over a network, at CVSS 9.8 — though Microsoft's own FAQ for that CVE describes exploitation as requiring an attacker already authenticated as at least a Site Owner, which sits oddly next to the CVSS vector's 'no privileges required'; and CVE-2026-55040, an authentication bypass in on-premises SharePoint Server's JWT token validation that Rapid7 and Microsoft disclosed jointly, with Rapid7's technical analysis following on August 11, 2026. CVE-2026-56164 was added to CISA's Known Exploited Vulnerabilities catalog first, on July 14, 2026, the day it was disclosed, and Microsoft's own record marks it exploited; CVE-2026-50522 followed on July 22, 2026, and CVE-2026-55040 on August 18, 2026. The fourth is CVE-2026-65660, a code-injection flaw that Microsoft's FAQ says requires 'an authenticated attacker with low-level access to an affected server.' Microsoft fixed it on August 11, 2026, then revised the advisory on September 25, 2026 to say it had reliable evidence of active exploitation — CISA added it to the KEV catalog that same day.
What is CVE-2026-55040?: CVE-2026-55040 is an authentication bypass in the JWT token validation of on-premises SharePoint Server. Rapid7 and Microsoft disclosed it jointly on July 14, 2026, the day the fix shipped. Rapid7 published its technical analysis on August 11, 2026, describing the impact as a remote, unauthenticated attacker bypassing authentication on a vulnerable SharePoint server and then performing operations as a SharePoint site user or administrator. CISA added it to the Known Exploited Vulnerabilities catalog on August 18, 2026, which is the point at which there is evidence of exploitation in the wild. One thing not to misread: the remediation due date attached to a KEV entry comes from Binding Operational Directive 26-04 and binds Federal Civilian Executive Branch agencies. It is not a legal deadline for a private company, and a short window is the catalog's normal shape rather than a severity signal. Check your own farm's patch state against Microsoft's advisory for the CVE, not against a version list in an article.
What can an out-of-support SharePoint farm actually do about a vulnerability like CVE-2026-55040?: Less than you would like, and that gap is the argument for migrating rather than a reason to despair. SharePoint Server 2016 and 2019 reached end of extended support on July 14, 2026 and have no Extended Security Updates program at any price — no purchasable bridge the way Exchange or SQL Server has. Microsoft did release one further security update for these versions after that date (August 11, 2026, which fixed CVE-2026-65660 among 27 CVEs for 2016 and 2019; the September 2026 release carried none), but nothing commits Microsoft to doing that again for the next one. Until the farm is migrated, everything else available is a compensating control: take the farm off the public internet, put authentication in front of it with a VPN or an authenticating reverse proxy, restrict and review farm-administrator access, monitor authentication logs for the anomalies you would look for after a compromise, and confirm your backups actually restore. Those measures reduce reachability and shorten dwell time. None of them substitutes for a patch, and all of them are stopgaps for a migration that still has to happen.
Did Microsoft release a security update for SharePoint Server 2016 or 2019 after end of support?: Yes, once so far. On August 11, 2026, four weeks after end of support, Microsoft released KB5002905 and KB5002906 for SharePoint Server 2016 and KB5002894 and KB5002896 for SharePoint Server 2019, fixing 27 CVEs across the two versions' packages, including CVE-2026-65660, which Microsoft and CISA flagged as exploited on September 25, 2026. The September 2026 release carried none for either version, and nothing commits Microsoft to another. It does not create an ESU program; the migration argument is unchanged.
What else reached end of support on July 14, 2026?: More than SharePoint, which is why the migration scope is usually bigger than teams expect. Microsoft's 2026 end-of-support list puts SharePoint Server 2016, SharePoint Server 2019, Project Server 2016, Project Server 2019, SharePoint Designer 2013, InfoPath 2013, SQL Server 2016, and SQL Server 2014 Extended Security Updates Year 2 all on the same date. If your SharePoint farm sits on SQL Server 2016, both tiers of that stack went out of support the same day. SQL Server 2016 at least has a paid three-year ESU ladder that began July 15, 2026; SharePoint has nothing equivalent at any price.
What are the migration paths from SharePoint Server 2019?: Three real paths: (1) full migration to SharePoint Online — the right answer for most organizations; (2) in-place upgrade to SharePoint Server Subscription Edition (SE) for organizations with regulatory data-sovereignty requirements; (3) selective hybrid — keep SharePoint 2019 for specific workloads with hard customizations or LOB integrations and move the rest to SPO.
How long does a SharePoint 2019 to SharePoint Online migration take?: For 50 users, 60–90 days end-to-end. For 200 users, 90–150 days. For 500 users, 150–240 days. The dominant variable is custom code and third-party solution dependencies — every InfoPath form, every farm-solution WSP, every workflow that doesn't translate cleanly to Power Automate adds time.
What does SharePoint Server Subscription Edition cost compared to SharePoint Online?: SharePoint SE is licensed per server plus per user CAL on a subscription model. For most mid-market environments, the three-year TCO of SharePoint SE — including hardware refresh, Windows Server licensing, SQL Server, backup, patching labor, and Microsoft 365 plans you're already paying for — runs 2–3x the SharePoint Online line item already included in most M365 plans. SE is the right answer when data sovereignty mandates it, not when it's cheaper, because it usually isn't.

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle and the Pacific Northwest, delivered USA-wide.

Share on LinkedIn Follow Pro IT NW