SharePoint Server 2019 EOL July 2026: Three Paths

If your organization is still running SharePoint Server 2019 in mid-2026, the dates that matter are short. Mainstream support ended January 9, 2024. Extended support ends July 14, 2026. There is no Extended Security Updates program for SharePoint Server — unlike Exchange Server, Microsoft did not build an ESU bridge. After July 14, 2026, your SharePoint farm stops getting security updates entirely.

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

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.

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

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 every SharePoint migration we've delivered.

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

1. SharePoint Server 2019 must be on the most recent CU. If you're behind, plan for the CU sequence first.
2. 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.
3. SQL Server upgrade. SharePoint SE supports newer SQL versions. Plan the SQL upgrade as a parallel project.
4. 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.
5. 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.

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.

The decision tree, simplified

What we recommend doing this week

1. 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.
2. 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.
3. 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.

Related reading

• Parallel decision tree for email infrastructure: Exchange 2019 EOL: your last six months.
• If your migration is M&A-driven and surfaces tenant consolidation work: Tenant-to-tenant M365 migration playbook.
• If the SharePoint move surfaces oversharing risk for an upcoming Copilot rollout: Copilot readiness: the 12,000-permission problem.
• Service detail: Microsoft 365 Migration.

Sources and further reading

• Microsoft Learn — SharePoint Server 2019 lifecycle
• Microsoft Learn — SharePoint Server Subscription Edition
• Microsoft Learn — SharePoint Migration Tool (SPMT)
• Microsoft Learn — SharePoint hybrid configurations

The 30-second version

SharePoint Server 2019 extended support ends July 14, 2026. There is no ESU program. 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. Two-business-day response 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.