How to migrate from Office Online Server to Collabora Online before January 1, 2027
Organizations that use Office Online Server for browser editing in SharePoint Server or another WOPI host need a replacement before its retirement on January 1, 2027. The core answer is that this is a rebinding of the editing service, and your documents stay where they are. The effort depends on how many hosts are involved, which formats and macros your users rely on, and how many people must be trained and cut over. Collabora Online is a self-hosted option built on LibreOffice technology that integrates through *WOPI*, and its server code is licensed under the Mozilla Public License 2.0 (MPL-2.0). Because scope drives cost and duration, the work is defined in writing before it starts.
In practice, the rebinding has four parts: remove the existing WOPI bindings from each host, point each host at the Collabora Online endpoint, restrict which servers may send WOPI requests, and confirm that both sides use HTTPS. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using the same protocol, preferably HTTPS, for the Collabora server URL as for the host. Confirm with your SharePoint administrators and with Collabora how your SharePoint Server version connects to Collabora Online and whether your version offers equivalent IP restrictions, since the supported integration path and configuration steps must be verified before scoping. Then test format fidelity with your own documents. Collabora Online handles docx, xlsx and pptx, but your templates, fonts and layouts decide whether a document looks right after the change.
Cost has two components. Planning, rebinding, testing and cutover are one-time work, and DeployOpen scopes that work in writing and quotes from the agreed scope. Collabora Online licensing is a separate, recurring line. According to the Collabora pricing page, the Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access, while the Enterprise plan for 100 or more users is quoted with volume discounts. Include both in your total cost of ownership. When requesting a quote, ask for the host inventory, the format and macro test plan, the cutover and rollback steps, user communication materials, and a list of items that recur after go-live.
Which Office Online Server capabilities map to Collabora Online and which need a decision
This table compares the main Office Online Server capabilities with their Collabora Online counterparts and flags where the migration needs a decision. Read each row as a starting point: the note tells you what to test, and the last column tells you which behavior to confirm against Collabora's integration documentation or your own test results. Items marked as requiring a decision usually affect users, admins or document owners, so settle them before cutover.
| Capability | Collabora Online equivalent | Migration note and what to confirm |
|---|---|---|
| Browser viewing and editing of docx, xlsx and pptx | Collabora Online edits Microsoft formats including docx, xlsx and pptx through WOPI hosts | Covered by the product's format support. Confirm with a representative sample of your own files, since layout, fonts and complex tables can differ from Office Online Server. |
| Co-authoring | Real-time co-editing of a document through the WOPI session, with all users on one document routed to the same server | Test simultaneous edits, comments and tracked changes. Route by WOPISrc in any load balancer, or co-editing sessions will split across servers. |
| WOPI host integration | Binding Collabora Online to the host through its WOPI discovery endpoint, with the host's allow list | Remove Office Online Server bindings first so the host does not hold two editor URLs. Confirm the exact binding steps for SharePoint Server in Collabora's integration documentation, since SharePoint support is not covered by the supplied facts. |
| PDF and legacy formats | Support for PDF, RTF and CSV, plus Visio files, as listed in the product documentation | Treat legacy Word binary formats and Visio drawings as test items, not assumptions. Record which formats users open for viewing only and which they must edit. |
| User and group access controls | Host-side permissions decide who can open or edit; Nextcloud Office can limit editor access by group | Office Online Server permissions map to your host's sharing model, not to Collabora itself. Decide whether view-only and edit rights will be enforced by the host, and confirm this in your own tests. |
| Macros and macro-enabled files | Macro behavior is governed by Collabora Online settings and the host, and is not equivalent to Office Online Server | Decision required. Inventory macro-enabled documents and confirm in Collabora's documentation how macros are handled before users are told which files still work. |
| Embedded objects and linked content | OLE objects and external links depend on the source format and what the editor can render | Decision required. Test embedded spreadsheets, charts and linked files on a sample set, and agree which content owners must rework before cutover. |
| SharePoint Server specific features | Features such as SharePoint-only co-authoring hooks or Office Online features depend on the host integration | Decision required. Confirm each SharePoint-specific feature you use against Collabora's integration documentation and your test results, and document any gaps for users. |
How WOPI rebinding replaces the old Office Online Server endpoints
The core idea of this migration is that the WOPI host keeps the files and the permissions, while Collabora Online only renders and saves documents on request. In a SharePoint Server estate, the host continues to decide who can open a file, whether the file is read-only or editable, and where the bytes live. When a user opens a document, the host hands Collabora Online a short-lived request that points back to the file, and Collabora Online fetches the content, lets the user edit it in the browser, and writes changes back through the same protocol. Nothing about the document library, its folders or its access model moves to Collabora Online, so the migration work is concentrated in the binding layer rather than in the content itself.
Rebinding starts with removing the old Office Online Server bindings. Before any new binding is created, inventory every place the host still advertises the old editor for a file type, including default handlers, per-type associations and any farm-level settings that override them. Once the old bindings are gone, point the host at the Collabora Online server URL. The Nextcloud administration manual recommends that the Collabora server URL use the same protocol as the host, preferably HTTPS, and that WOPI requests be restricted to the Collabora server addresses. That pattern is a useful comparable, but the exact SharePoint Server binding steps, the discovery endpoint layout and any trust or certificate settings must be confirmed in current Collabora and Microsoft documentation before the change is scheduled.
Documented binding and deployment paths for the move
Collabora Online has several documented ways to run and bind, and each one changes how you remove Office Online Server and where users land. The cards below cover the deployment options, the routing rule that keeps co-editing working, the WOPI allow list, group limits, and the CODE edition, so you can confirm each choice with Collabora and your platform owner before cutover.
Choose a deployment method
Collabora Online can run from Docker images, system packages or Kubernetes, and large deployments can add the Collabora Online Controller. Your choice sets who patches the service, how it is restarted, and how it sits behind your existing proxy. Ask Collabora which method and which version branch it supports for your SharePoint Server estate, and confirm the package signing and update process your team will follow. Confirm the Controller requirements with Collabora before you commit to Kubernetes.
Set replicas manually and route by WOPISrc
The official Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste. Replica counts are therefore set by hand, and the load balancer must route by the WOPISrc parameter so everyone editing one document reaches the same pod. Plan the replica count and the ingress rule with your platform team. Confirm with Collabora how your chosen ingress (Nginx, HAProxy or OpenShift Router) handles this routing.
Restrict WOPI hosts with an allow list
Office Online Server bindings relied on Microsoft's own host list, so this is a new control you must build. The Nextcloud administration manual recommends limiting WOPI requests to the Collabora server IP addresses and using the same protocol for both URLs, preferably HTTPS. Inventory every WOPI host that will call Collabora, including SharePoint Server farms, and confirm the allow list syntax and any proof key requirements with Collabora before you bind the first site.
Limit editing by group
In Nextcloud Office, administrators can restrict which groups can use the editor and which groups can edit rather than only view. Map your current Office Online permissions, such as view-only libraries and restricted contributors, to groups in your identity source before cutover. Confirm with your host platform owner whether equivalent group controls exist for each WOPI host you plan to bind, since these settings are host-specific and not all hosts expose them.
Treat CODE as a test edition
CODE is the free edition, released roughly once a month as a rolling release. Collabora describes it as suited to testing, home use or small teams and not recommended for production. Use CODE only in a pilot or test environment that mirrors your bindings, and confirm with Collabora which supported edition, such as the Business or Enterprise plan, you will run in production. Business pricing is listed at 3 euros per user per month for up to 99 users, according to Collabora's pricing page, so confirm the current terms in writing.
The migration sequence from inventory to decommission
The sequence moves from inventory to decommission in seven phases, and each phase ends with a written gate and a named sign-off. It produces a tested Collabora Online server, a documented record of format differences, and a record showing that Office Online Server was removed from every host. Confirm the gate owners with your own governance before the work starts.
Inventory WOPI hosts, file types and users
Record every SharePoint farm, Office Online Server binding and other WOPI host that opens documents, along with the file types, macro-enabled documents, templates and user groups each one serves. Application owners and the security team review the list together. The gate is a signed inventory that names an owner for each host and flags every macro-enabled file and line-of-business dependency for a separate decision. Later phases do not start until that sign-off is recorded.
Stand up a pilot on non-production Collabora
Install Collabora Online on a non-production server using the deployment method your platform team has chosen, with TLS, a reverse proxy and a WOPI host allow list limited to the hosts from the inventory. Bind a small pilot group of users on the pilot host only, then confirm that documents open, save and co-edit from the browser. The gate is a pilot checklist signed by the platform engineering lead and the security owner, confirming that the server answers only the approved hosts. Production bindings stay untouched.
Run format fidelity testing on representative documents
Build a sample set from the inventory that includes docx, xlsx and pptx files with tracked changes, comments, embedded objects, custom fonts and complex layouts. Open each file in Office Online Server and in Collabora Online, then compare rendering, editing, saving and round-trip results. Log every difference with its severity and a business owner's decision. The gate is a fidelity sign-off from the document owners for each file category, with accepted differences recorded and blocking issues returned for fixes or documented workarounds.
Coexist both bindings for a defined group
Bind a defined group of production users to Collabora Online while the rest of the organization stays on Office Online Server, with both WOPI bindings active in the same environment. Monitor editing sessions, save errors, lock behavior and help desk tickets for that group, and keep a documented rollback that rebinds the group to Office Online Server. The gate is a parallel run report, signed by the service owner and the help desk lead, showing no open high-severity defects and a rollback that has been tested.
Communicate the change and prepare users
Tell users what changes in the editor, how to open files from each host, and where to report problems, using the material refined during the parallel run. Brief help desk staff on the known format differences, the workarounds and the escalation path. Name a contact for each affected department. The gate is a communication plan approved by the service owner and the change manager, with the parallel run issues answered in a user FAQ before any further group is moved.
Cut over by host or by group
Move the remaining hosts or user groups to Collabora Online in agreed waves. For each host, remove the Office Online Server binding once its users have moved and its open sessions have closed. Hold a go or no-go check before each wave and keep the previous binding documented until the wave is confirmed stable. The gate for each wave is a cutover record signed by the application owner and the service owner, confirming that the old binding is removed, that test documents open correctly and that no sessions remain on the old path.
Decommission the Office Online Server farm
Confirm that no host still references the Office Online Server farm, then remove any remaining WOPI bindings and DNS entries. Shut down and delete the farm according to the retention and backup decisions made with the compliance team, and keep configuration exports and change records as evidence of the migration. The gate is a decommission sign-off by the infrastructure owner, the security lead and the compliance owner, confirming that no bindings remain and that the retained records are stored where your policy requires.
How to test format fidelity before the cutover date
Format fidelity testing decides whether the documents your people already hold will survive the move from Office Online Server to Collabora Online, so start it before any cutover date is fixed. Build the test set from your own files rather than vendor samples. Pull a sample from each shared location, such as SharePoint libraries, file shares and archives, and cover every format you expect to edit: docx, xlsx and pptx, plus PDF, RTF, CSV and Visio. Collabora's Collabora Online product page lists the supported formats, but that list does not tell you how a given file from your organization will render. Group the files by complexity: plain text, tracked changes, comments, charts, embedded objects, custom fonts and macro-enabled files. Record each file's source, owner and the feature that makes it complex, so the results can be traced back later.
For each file, open the original in Office Online Server and in Collabora Online through the same WOPI binding, then compare three things: how the document renders on screen, how it prints or exports to PDF, and what the saved copy looks like when reopened in desktop Office. Check pagination, table layout, chart appearance, font substitution, comment anchors, tracked change markup and the behavior of embedded objects. Log every difference as a defect with the file name, feature class, severity and a screenshot. Then decide which defects block cutover. A reasonable rule is that any loss of content, altered numbers in spreadsheets, broken links, or changed signatures or protected sections blocks cutover, while minor spacing shifts may be accepted with user guidance. Confirm each defect class with a pilot group, because the impact depends on how your users work. Macro-enabled files need their own track, covered in the sibling topic on macros.
What drives the cost and duration of an Office Online Server replacement
This table compares the main drivers of a move off Office Online Server onto self-hosted Collabora Online, with who pays for each and whether it is one-time or recurring. Use it to decide which items your written quote must price separately, since the subscription line depends on user count.
| Driver | Why it changes cost or effort | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| WOPI hosts and tenants | Each host or tenant needs its own WOPI binding, allow list entry and test pass, so more hosts add configuration and verification work. | One-time | A per-host list of bindings, the tenants covered and the test cases for each. |
| User count and subscription tier | Collabora's Business plan is priced per user per month for up to 99 users. Enterprise is quoted for 100 or more users with volume discounts, so headcount sets the subscription line (per the Collabora pricing page). | Recurring | The tier that applies to your user count, the quoted per-user basis, and what the support and SLA terms cover. |
| Concurrent editing peaks | Sizing follows simultaneous editors, not total accounts. Peaks drive server count and pod resources. | One-time sizing, recurring capacity | The concurrency assumptions used, the load test results and the number of servers or pods proposed. |
| Pod resources and replica control | The Helm chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Horizontal autoscaling is disabled, so replicas are set manually. | Recurring infrastructure | Whether the quote includes the pod sizing, the replica plan and who adjusts replicas during peaks. |
| WOPISrc-aware load balancing | All users editing one document must reach the same pod, so the load balancer configuration and its testing add effort. | One-time build, recurring operation | Ingress choice (Nginx, HAProxy or OpenShift Router), the routing tests and the operations handover. |
| Document volume and format mix | Office formats such as docx, xlsx and pptx, and legacy or macro-bearing files, need fidelity testing before cutover. Heavier mixes take longer to verify. | One-time | The sample size, the format list, the fidelity test method and who signs off results. |
| Macros and line-of-business dependencies | Macro-enabled documents and Office automation tied to line-of-business systems need inventory, redesign or retirement decisions before users can move. | One-time, with possible ongoing change work | An inventory of macros and integrations, what is redesigned versus retired, and the test scope for each dependency. |
| Identity and network controls | Restricting WOPI requests to Collabora server addresses, aligning protocols (preferably HTTPS) and setting group-based editing rights add configuration and approval steps. | One-time, with recurring review | The controls to be configured, who approves the access model and the evidence produced for review. |
| User communication and training | Users need notice of the new editing experience, the cutover date and any changed behavior, which takes planning and material production. | One-time | Communication plan, training materials, support coverage during cutover and who delivers them. |
| Parallel run length | Running Office Online Server and Collabora Online side by side extends the period of two platforms, bindings and support. Length depends on your retirement plan and the January 1, 2027 Office Online Server retirement date. | One-time, with running cost during overlap | The parallel run window, the exit criteria for ending it and the cost of keeping both platforms available. |
What usually goes wrong when Office Online Server is replaced
Most failed replacements are not caused by Collabora Online itself. They come from leftover configuration, load balancing that splits co-authors, untested document formats, hidden macro dependencies, and a rushed cutover. Each card below names the early signal that shows the risk is already happening.
Old WOPI binding stays active
After cutover, the old Office Online Server discovery endpoint can still be reachable from SharePoint Server, so some users open documents in the retired editor while others open them in Collabora Online. Remove the old binding with SharePoint's WOPI configuration commands, then confirm the new Collabora discovery endpoint is the only active one. Early signal: support tickets describe two different editor interfaces for the same library, or server logs show WOPI requests still arriving at the retired host after the change window closes.
Load balancer ignores WOPISrc
If the load balancer distributes requests by connection or round robin rather than by the WOPISrc parameter, co-authors of one document land on different Collabora pods and cannot see each other's changes. The official Helm chart notes that all users editing one document must reach the same pod, and that autoscaling is disabled for this reason. Check routing with two test sessions on the same file before go-live. Early signal: edits appear, then vanish, or users report that copy and paste fails during shared editing.
Format defect found after cutover
Documents that rendered correctly in Office Online Server can show shifted tables, altered fonts, broken charts or lost comments in Collabora Online. Build a fidelity test set from your own high-use files, including complex docx, xlsx and pptx content, and compare renderings before users depend on them. Agree in writing who decides whether a difference is acceptable. Early signal: help desk tickets naming specific file types or templates within the first days of rollout.
Undocumented macro and add-in dependencies
Office Online Server never ran VBA macros in the browser, but some line-of-business workflows depend on macro-enabled templates, add-ins or scripted buttons in SharePoint libraries. Macros are disabled in Collabora Online, so those workflows can stop working without warning. Inventory macro-enabled files, add-ins and custom actions before selecting the cutover date. Early signal: users report buttons that do nothing or documents that open with a security prompt they have never seen.
Users editing during the switch
Documents open in the old editor during cutover can hold locks or unsaved changes that conflict with edits made in Collabora Online afterward. Freeze write access for the migration window, announce the exact time, and ask owners to save and close open files before the switch. Confirm that lock behavior is consistent across both editors during the overlap period. Early signal: version conflict messages, duplicate copies of the same file, or lock prompts that do not clear after the user closes the document.
CODE build deployed to production
CODE is the free edition, released roughly monthly as a rolling release, and Collabora does not recommend it for production. Teams that start with the free image in a pilot sometimes keep it in production because it works. Choose the Business or Enterprise plan path, or confirm your support model, before production sign-off. Early signal: the image tag in your deployment is a CODE build, and no support agreement or security update channel is named in the change record. Collabora's Business plan lists signed security updates and long term support at 3 euros per user per month for up to 99 users, according to Collabora's pricing page.
What buyers ask before moving from Office Online Server to Collabora Online
What drives the cost of moving from Office Online Server to Collabora Online?
The cost depends on how many WOPI bindings you run, how many document types and users are involved, and who performs the work. Software is one part of the bill. The Collabora pricing page lists the Business plan at 3 euros per user per month for up to 99 users, so licensing scales with headcount. Services are a separate line. Ask each quote to split one-time work (inventory, server build, rebinding, fidelity testing, cutover) from recurring items (subscription, patching, support). Costs rise with custom macros, line-of-business integrations, the number of host platforms and the number of environments you must validate. Costs fall when the inventory is complete before scoping starts.
How long does an Office Online Server migration usually take?
No single duration applies, because the length follows the work in front of you. The main drivers are the number of SharePoint sites, libraries and other WOPI hosts still bound to Office Online Server, the volume and variety of file types, and how many people must sign off on compatibility results. Environment count matters as well, since a test, staging and production path takes longer than a single server build. Change windows set the final pace, because cutover usually needs a planned period when editing is paused. Ask any provider to state its assumed duration and the conditions that would extend it, then check that assumption against your own inventory before you commit to a date.
What must our team provide before a migration starts?
Three inputs determine whether the schedule holds: a complete inventory, a representative test document set and a named owner. The inventory lists every WOPI binding, host platform, user group, document type and integration that calls Office Online Server today. The test set should include live business files with macros, embedded objects, tracked changes, templates and complex spreadsheets, handled under your data protection rules. The named owner decides format exceptions and approves user communication. Agree change windows with business units early. Also provide access to DNS, TLS certificates, identity settings and the SharePoint or host administration needed to rebind each platform.
Can our internal team migrate to Collabora Online without a partner?
Often yes, if the team has Linux server administration, reverse proxy and identity skills, plus time to run compatibility testing. The work is more than installation. It includes removing the old WOPI bindings, binding Collabora Online, validating formats, handling exceptions and cutting over without losing edits. Teams that already run other WOPI integrations usually have a head start on the binding work. A partner adds the most value where staff are stretched, the inventory is large or the deadline is fixed. Decide by listing the skills gaps and the hours your staff can release, then compare that list against a written scope. Confirm the gap list with your own engineers before you decide.
How does the January 1, 2027 retirement affect our planning?
Office Online Server reaches retirement on January 1, 2027, so every WOPI binding that still points to it needs a replacement before that date. Plan backwards from the deadline. Allow time for the inventory, the build of Collabora Online in your infrastructure, fidelity testing, user communication and a rollback path. Organizations that start late compete for the same change windows and staff. Check whether any host platform you run needs its own upgrade before it can point to a new editor. Confirm the exact retirement terms against your contract and installed product version, since those govern your final timetable.
What does a fixed-scope DeployOpen engagement cover?
A fixed-scope engagement covers the deliverables agreed in writing before work starts. For this migration, those typically include the inventory review, the Collabora Online build in your environment, WOPI binding changes, a fidelity test plan with results, user communication material and cutover support. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. DeployOpen does not issue audit reports or certifications. Scope, deliverables and timelines are agreed in writing, and the quote follows from that written scope. Ask for exclusions in writing too, such as macro remediation or custom integrations, so you know what sits outside the agreement.
Which Collabora Online plan fits our user count?
Collabora describes the free CODE edition as suited to testing, home use or small teams and not recommended for production. For production, the Collabora pricing page lists the Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. Confirm your user count, including shared and service accounts, before you choose. Ask the quote to show subscription terms separately from implementation services so you can compare each line.
How DeployOpen scopes, delivers and supports the migration
DeployOpen treats the move from Office Online Server to self-hosted Collabora Online as a written, fixed-scope engagement covering WOPI binding, format testing, user communication and cutover. Each stage produces documented deliverables that your team can review, run and keep after the engagement ends.
How we scope
- Inventory every SharePoint Server and other WOPI host that currently calls Office Online Server and record each binding.
- Agree in writing which hosts, document types, user groups and environments the migration covers.
- Define the format fidelity test set, acceptance criteria and the cutover window before any build work starts.
How we build
- Deploy Collabora Online in your infrastructure, then bind it to each WOPI host and remove the old Office Online Server bindings.
- Restrict WOPI access to approved host addresses and use HTTPS for the Collabora server URL, following vendor guidance.
- Run the agreed fidelity tests on docx, xlsx and pptx samples and log every difference found for your review.
How we hand over
- Provide documentation of the final WOPI bindings, configuration, network rules and rollback steps for your operations team.
- Deliver user communication material and a cutover runbook that your staff can approve and execute.
- Walk your engineers through monitoring, updates and the fidelity test results before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after cutover, scoped separately in writing.
- Agree a patch and update routine for Collabora Online so security releases are applied on a schedule you approve.
- Ask your quote to name who maintains each component after handover so ownership is clear from day one.
