The same binding. An editor that keeps your macros.

Microsoft ends support for Office Online Server on 1 January 2027. SharePoint Server itself is supported far beyond that, so the farms stay and the editor has to be replaced. SharePoint does not care who answers: it binds to a WOPI server, and SumOffice answers that protocol — the same New-SPWOPIBinding, the same zones, the same proof keys. We measured it on SharePoint Server Subscription Edition 16.0.14326.

What was measured

Binding	Eight bindings from one discovery document: Word DOCX, Excel XLSX / XLSM / XLSB, view and edit, in the `internal-https` zone. `view` is the default action, exactly as Office Online Server declares it.
Opening	A macro workbook and a document with five pictures opened from a Documents library with SharePoint's own button, in SumSheet and SumDoc.
Saving back	The edit landed: `PutFile` 200, WOPI PutFile Success in the ULS log, and new versions in the library attributed to the user who made them.
Signatures	SharePoint verifies the proof key on every request. 13 checks, zero refusals. Two editors behind one discovery must sign with one key — ours do.
What came back	The VBA project byte for byte and all five pictures byte for byte, with the edit in place. What this does not say: the rounds used a small fixture workbook from our corpus, and we have since opened that fixture in Microsoft Excel on its own — it asks to be repaired before any round touches it. So we do not claim a silent Excel here. We claim it where we measured it on a real workbook: Nextcloud and Seafile. The same round on a real workbook is being repeated for SharePoint.
Not counted	People, sites, documents. Evaluation is free with no time limit; production is the per-application license — no per-user meter, which is the part that usually decides this comparison.

Step 1 — start the editors, on https

SharePoint will not bind to a plain-http WOPI server, and the proof keys are not optional. Two editors behind one address, one merged discovery.

mkdir sumoffice-sharepoint && cd sumoffice-sharepoint
git clone https://github.com/SumOfficeApp/sumoffice-docker && cd sumoffice-docker/nextcloud
cp env.example .env    # PUBLIC_URL=https://office.example.com
docker compose up -d
curl -s https://office.example.com/hosting/discovery | head -c 300

Step 2 — bind SharePoint to them

In the SharePoint Management Shell, on a farm server:

Remove-SPWOPIBinding -All:$true -Confirm:$false
New-SPWOPIBinding -ServerName "office.example.com" -Application Word
New-SPWOPIBinding -ServerName "office.example.com" -Application Excel
Get-SPWOPIBinding | Format-Table Application, Extension, Action, IsDefaultAction, WopiZone
iisreset

Pass -Application. Without it the cmdlet walks every application in the discovery document and stops on «already exist», because the zone that serves other hosts declares the macro-enabled types twice, under two application names. With -Application Word and -Application Excel you get exactly the eight bindings above.

Check the zone: your farm's WOPI zone (Get-SPWOPIZone) must match the zone the bindings landed in — internal-https for a farm that talks to the editor over the internal network, external-https for one that goes out and back.

Step 3 — open a workbook

In a document library, open any .xlsx, .xlsm or .docx. The editor opens in the SharePoint page; Doc.aspx?sourcedoc={id}&action=edit is the direct form if you want to test it without clicking.
Edit and save: the file goes back through WOPI and SharePoint records a new version against the user.
Download it and open it in Excel: the VBA project and the formulas are the ones you put there.

Two things that cost us a day

The token arrives in a header	SharePoint passes the access token as `Authorization: Bearer`, not only in the query string. An editor that reads only the query answers 401 and SharePoint shows you «Sorry, something went wrong» with nothing useful on screen. Fixed in both our editors.
The default action	If no action in the zone is marked `default`, all eight bindings come back with `IsDefaultAction=False` and clicking a file does nothing helpful. Office Online Server marks `view` as default; so do we.

When something does go wrong, the answer is in the ULS log: raise SharePoint Foundation: WOPI to Verbose and search by the correlation id from the error page.

Why this comes up now

Office Online Server loses support on 1 January 2027. After that date it keeps running and stops being patched — which, for an editor that renders documents from the whole organization, is the part security will ask about.
SharePoint Server Subscription Edition is supported well past that. The farm is not the problem; the editor is.
The documents in those farms are the reason people stayed on-premises: workbooks with macros, with Power Query, with twenty years of formulas. An editor that drops the VBA on save does not solve this — it moves the problem to the people who own those files.

Before you move a department, run its workbooks through Check my Excel file: it names every macro, every function and every data source the engine knows or does not know, in seconds, without running anything. The other hosts we measured →

Then

Tell us the farm version and the deadline — we will say plainly whether we fit it and by when.
Order a change under your process — your zones, your SSO, your reverse proxy: from 150 €, price and date before we start.