Your SharePoint Farm Is Now Unpatched: The Emergency Support Playbook

The deadline passed. Most farms did not notice.

July 14, 2026 was the end of extended support for SharePoint Server 2016 and SharePoint Server 2019. If you are reading this from an on-premises farm, nothing dramatic happened that day. Your servers came up. Your content databases mounted. Your users logged in and complained about search, the same as always.

That is precisely the problem. This deadline does not announce itself. It changes your risk profile silently and permanently, and the first visible symptom is usually an incident.

Here is what actually changed, what did not, and what a genuine emergency looks like on an unsupported farm.

---

What stopped on July 14

| What ended | Practical consequence |

|---|---|

| Security patches | Vulnerabilities disclosed after this date are never fixed on 2016/2019 |

| Bug fixes and performance updates | Known defects stay in place permanently |

| Microsoft technical support | No support case can be opened — free or paid |

| Maintained documentation | Official Microsoft Learn content is no longer updated |

What did NOT stop

• Your farm still runs. There is no kill switch and no forced shutdown.
• Content databases still mount and still serve.
• Your users can still work, mostly unaware anything changed.
• Your licensing is still valid — this is a support boundary, not a licensing one.

This asymmetry is the trap. Everything that would prompt urgency is invisible, and everything visible looks fine.

---

The ESU misconception that will cost someone a breach

When Windows Server 2012 and SQL Server 2012 reached end of support, Microsoft offered Extended Security Updates — a paid program that bought additional years of critical patches while you planned a migration. Many enterprises budgeted for exactly that and moved on.

There is no ESU program for SharePoint Server. None. There is nothing to purchase, at any enterprise agreement size, at any price.

We are flagging this deliberately because we have already had conversations this year with IT leadership who had a line item in their FY27 budget for "SharePoint ESU." That line item cannot be spent. If your risk register assumes a paid extension exists, correct it now — the mitigation you think you have is not available.

---

Your three supported paths

1. SharePoint Online (Microsoft 365)

The default destination for most organizations. Patching becomes Microsoft's problem permanently, and you land on the platform where every new capability — including everything in the Copilot line — ships first. The work is content migration, information architecture, and customization remediation, not infrastructure.

2. SharePoint Server Subscription Edition

The supported on-premises path. Subscription Edition follows the Modern Lifecycle Policy and will not reach end of support before December 31, 2035. If data residency, latency, air-gapped requirements, or regulatory constraints keep you on-premises, this is the answer — and it is a genuine answer, not a holding pattern.

3. Hybrid

Regulated or latency-sensitive workloads stay on Subscription Edition; collaboration and general document management move to SharePoint Online. More moving parts, but it is frequently the right call in healthcare, financial services, and government environments where a subset of content genuinely cannot leave the building.

What is not on the list: staying on 2016 or 2019 indefinitely. That is not a fourth option — it is an accepted risk, and it should be written down, owned by a named executive, and reviewed on a schedule.

---

The related deadline people keep missing

April 2, 2026 was the full retirement of SharePoint Add-Ins and Azure Access Control Service (ACS) authentication.

If your farm still runs legacy add-ins that authenticate through ACS, those integrations have already stopped working or are actively failing — and this is a distinct problem from the July support deadline. We see these two conflated constantly. Migrating to Subscription Edition does not fix an ACS dependency. Add-in modernization is separate remediation work, and it is the more common source of the "half our line-of-business integrations broke and nobody knows why" call.

---

What we actually treat as an emergency

Not everything urgent is an emergency. We run four categories on the emergency track:

Outage. A business-critical site collection is down or partially unavailable. Users cannot reach content they need to do their jobs today.

Suspected compromise. Anomalous access patterns, unexpected permission changes, unexplained administrative activity, or any indicator of compromise on a farm that is no longer receiving patches. On an unsupported farm this category gets escalated harder, because your remediation options are narrower.

Data loss or corruption. Failed restores, corrupted content databases, broken version histories, retention or deletion events that removed something they should not have.

Failed or stalled migration. Content is inconsistent between source and target, a cutover window is closing or has closed, or a migration tool has failed partway and left the environment in an indeterminate state. These are time-critical in a way that ordinary tickets are not — the longer an inconsistent state persists, the harder reconciliation becomes.

Everything else — slow search, permission questions, "how do I," feature requests, planning — runs on standard support with normal response targets. Calling everything an emergency is how organizations end up with no emergency capacity when they need it.

---

How our 24/7/365 emergency response works

Intake is always open. Emergency requests are taken 24 hours a day, every day of the year, including holidays. There is no queue that opens at 8am local time.

One-hour response commitment on critical issues. Response means a qualified SharePoint engineer engaged on your problem — not an automated acknowledgement, not a ticket number, not a callback slot next business day.

You do not need an existing contract. We engage on genuine emergencies for organizations we have never worked with. Sorting out commercial terms while a farm is down helps nobody.

Senior-led triage. The person on your first call is someone who has done this before on a farm like yours. Escalation paths exist, but they run upward from an experienced starting point rather than upward from a script.

Read-only first. Our standard opening posture on an unfamiliar environment is read-only diagnostic access. We establish what is actually happening before anyone changes anything — the fastest way to turn an incident into a disaster is a confident change made on an incomplete picture.

The realistic sequence on a farm we have never seen

| Phase | What happens |

|---|---|

| Hour 0–1 | Response, triage call, scope and blast radius established |

| Hour 1–4 | Read-only diagnostic access, log and configuration review, containment recommendations |

| Hour 4–24 | Root cause, remediation plan, execution against an agreed change window |

| Post-incident | Written root cause, hardening recommendations, migration or upgrade path if the incident traces back to the unsupported platform |

We are deliberately not promising a fixed resolution time. Anyone who quotes you a guaranteed fix window for an unseen farm is guessing, and you should treat that as a signal about the rest of their commitments.

---

Compensating controls if you are staying on 2016/2019 through a transition

Migration takes months. If you have a defensible reason to still be on an unsupported version while that work happens, get these in place and documented:

• Network isolation. Reduce the reachable surface. An unpatched farm should not be broadly exposed, and it should certainly not be reachable from the public internet without a hardened, monitored path in front of it.
• Elevated monitoring. Increase logging retention and alerting on administrative actions, permission changes, and authentication anomalies. Your detection capability is now doing work your patching used to do.
• Tightened access. Audit farm and site collection administrators. Remove standing privilege that is not actively needed. Nested group sprawl is where quiet over-permissioning lives.
• Verified backups. Not "backups exist" — backups *restored and verified* on a schedule. An untested backup is a belief, not a control.
• Documented risk acceptance. Named executive owner, stated compensating controls, defined review date, and a committed migration timeline. This is what an auditor or a cyber insurance underwriter will ask for, and producing it after the question is asked is far worse than producing it before.

That last one matters more than teams expect. HIPAA Security Rule, SOC 2, PCI DSS, and most cyber insurance policies contain language about running supported software or patching known vulnerabilities in reasonable time. "The vendor formally stopped issuing patches thirteen months ago and we had no documented plan" is not a position you want to defend during a claim.

---

The honest summary

Your farm running fine today is not evidence that the deadline did not matter. It is evidence that the risk is cumulative and the failure mode is delayed. Every month on an unsupported platform adds unpatched vulnerabilities that will never be fixed, and the gap only closes when you migrate or upgrade.

If you are on 2016 or 2019 right now, you need two things: a migration or upgrade decision with a real date attached, and a plan for what you do if something breaks before you get there.

If something is broken right now, our emergency intake is open — contact us or see Emergency SharePoint Support. If you are planning the move rather than reacting to an incident, SharePoint Migration is the place to start.