Office Online Server end of life: what it means for SharePoint Server SE

What exactly ends on 31 December 2026

Office Online Server reaches the end of its support lifecycle on 31 December 2026. Microsoft announced the date in October 2025: after it, Office Online Server receives no security updates, no bug fixes and no technical support, and it is not supported in any configuration, including together with SharePoint Server Subscription Edition.

Microsoft has also said it will not actively block Office Online Server in SharePoint Server. The software keeps running, but every vulnerability found from 2027 on stays open. For most organisations that is the real deadline: a server that opens every Word, Excel and PowerPoint file in the company is exactly the kind of system that security policies require to be patched.

There is no on-premises successor. Microsoft's recommended path is Microsoft 365. For organisations that stay on SharePoint Server Subscription Edition, Microsoft names Microsoft 365 Apps for enterprise and Office LTSC 2024 as the supported desktop clients for documents on those servers.

SharePoint Server SE itself stays supported

SharePoint Server Subscription Edition follows Microsoft's Modern Lifecycle Policy. Microsoft has committed that it will not reach end of support before 31 December 2035. It receives a public update every month, and each update is supported for one year, so a farm has to stay current to remain supported.

That creates the gap this guide is about: SharePoint stays, the component that showed documents in the browser goes.

What breaks in SharePoint Server SE without a WOPI client

SharePoint Server does not render Office documents itself. It hands them to a WOPI client (Web Application Open Platform Interface), until now Office Online Server. Without one:

• Browser viewing and editing stop. Clicking a Word, Excel or PowerPoint file no longer opens it in the browser. Users need desktop Office, or the browser downloads the file.
• Previews disappear. Thumbnails in document libraries and hover previews in SharePoint search results come from the same WOPI client, and Microsoft no longer supports them once Office Online Server is gone.
• Excel features tied to Office Online Server stop, such as rendering in the Excel Web Part.
• Locked-down and shared machines suffer most: without a locally installed Office, users cannot read documents at all.

Your options, compared

Every option below is valid for someone. The right one depends on two questions: may your documents leave your network, and do you need editing in the browser today?

Option	Data stays on-premises	Viewing in the browser	Editing in the browser	Effort
Keep Office Online Server, unsupported	Yes	Yes	Yes	None now; the security risk grows every month
Desktop Office only (no WOPI client)	Yes	No	No (desktop apps only)	Low, but previews and browser viewing are lost
Microsoft 365 / SharePoint Online	No	Yes	Yes	High: content migration, licensing, change management
Open-source office suite (Collabora Online, ONLYOFFICE Docs)	Yes	Yes	Yes	Medium: a new server platform, usually Linux; the vendors document SharePoint SE integration
Dedicated OOS replacement (Office Render Engine)	Yes	Yes	Not yet (view-only today)	Low: the same WOPI binding, on Windows Server

As of October 2026. Collabora and ONLYOFFICE describe their SharePoint SE integration on their own websites; neither option, including ours, is certified by Microsoft. Test search previews and your authentication setup in a pilot, whichever you choose.

Keep OOS unsupported only as a short bridge with a dated exit plan. Desktop Office only is Microsoft's supported fallback if browser access does not matter to you. Microsoft 365 is the right answer if moving to the cloud is already planned; Microsoft's SharePoint Migration Tool does not list Subscription Edition as a source, so check your migration tooling early. Open-source suites fit if you need editing in the browser now and can run a Linux service. A dedicated replacement fits if your documents must stay on-premises and viewing in the browser is what your users need.

How to migrate, step by step

The switch itself is small: SharePoint talks to whichever WOPI client its bindings point to. The work is in preparing it well, so that it is uneventful on the day.

1. Take inventory

On a SharePoint server, in the SharePoint Management Shell, record what you have today:

Get-SPWOPIZone
Get-SPWOPIBinding | Select-Object ServerName, Application, Extension, Action -Unique |
  Export-Csv C:\Wopi\wopi-bindings-before.csv -NoTypeInformation

Note every farm and zone bound to Office Online Server, the file types your users open, and integrations that rely on previews: search, Excel Web Parts, custom solutions. Keep the export: it is your rollback reference.

2. Prepare the new WOPI client

Whichever replacement you choose, the same SharePoint requirements apply:

• HTTPS with DNS names, not IP addresses. Plain HTTP is not something to plan for in production.
• Certificates trusted on both sides. The farm must trust the WOPI client's certificate and the client the farm's. If the certificate comes from an internal CA, import the CA into the SharePoint servers' trusted root store and roll it out to browsers.
• Firewall. Users' browsers and the SharePoint servers must reach the WOPI client on port 443.
• Discovery. https://<wopi-client>/hosting/discovery must answer from every SharePoint server before you bind.

3. Test on a test farm or a separate zone

Bind the new client on a test farm first, or start with selected file types only. Open real documents from your own libraries, not just samples, and test as an ordinary user: the farm, setup and application pool accounts cannot get WOPI tokens, so testing with them always fails. Check your authentication setup (NTLM, Kerberos, claims) and the search previews.

4. Switch the binding

Remove only the Office Online Server bindings, then create the new ones and set the zone to match how users reach SharePoint:

Remove-SPWOPIBinding -Server "oos.contoso.local" -Confirm:$false
New-SPWOPIBinding -ServerName "ore.contoso.local"
Set-SPWOPIZone -Zone "internal-https"

Avoid Remove-SPWOPIBinding -All: it also removes bindings that other applications may rely on. No reboot and no IIS reset are needed; new sessions use the new client right away.

5. Keep a rollback ready

Rolling back means reversing step 4 with the server names swapped:

Remove-SPWOPIBinding -Server "ore.contoso.local" -Confirm:$false
New-SPWOPIBinding -ServerName "oos.contoso.local"
Set-SPWOPIZone -Zone "internal-https"

Compare the result with the export from step 1. Keep the Office Online Server machine available until the new client has run through a normal working week.

6. Tell your users what changes

Users mostly notice that documents open in the browser again, or keep doing so. Tell them what differs: with a view-only replacement, editing opens desktop Office; with an open-source suite, the editor looks different from Microsoft's. A short note before the switch and a contact for problems saves most of the help desk calls.

Frequently missed details

• Plan before the holidays. 31 December falls in a change freeze for many organisations. Aim to switch in November or early December 2026.
• Every zone counts. If users reach SharePoint through different URLs, check that the WOPI zone matches the one they use.
• Fonts. Install the fonts your documents use on the WOPI client server, or expect substitutes.
• Proof keys. If the WOPI client rotates its signing key, run Update-SPWOPIProofKey -ServerName <name> on the farm.