Upgrading Collabora Online from 25.04 to 26.04: when and why to move
Move to 26.04 when your team has time to test it against your WOPI host, and do not rush it because the 25.04 branch is still supported. Collabora Online 26.04 was announced on July 23, 2026, and the 25.04 branch was still receiving point releases, with 25.04.13 released on September 21, 2026, according to the Collabora Online 25.04 release notes. That gives a team running 25.04 behind Nextcloud or another WOPI host room to plan. The headline change is an optional AI assistant across Writer, Calc and Impress. It is off by default, and administrators choose the AI provider and whether that provider is hosted externally or on infrastructure they control. If you do not need the assistant, the case for moving rests on the other changes in the release notes and on staying within a supported branch, so check the Collabora Online release notes before you commit a date.
Confirm the supported path before planning. The 26.04 announcement post on the Collabora Online forum describes the release and its changes, and it is the right place to check whether a direct move from 25.04 is the recommended route for your installation type. Ask Collabora or your partner to confirm the package or image tags for your deployment method (Linux packages, Docker or Kubernetes), and whether any configuration keys changed between the two branches. Write down the current 25.04 point release on each server, because the answer determines which fixes you already carry. If you run a CODE build rather than a supported release, factor in the separate move to a subscription before you change branches.
If you enable the AI assistant, treat it as a new data flow, not a display feature. Document where prompts and document content would go, who approves the provider, and whether the Nextcloud side needs its own review before users see the option. Keep the assistant disabled in the first test environment so that the editing upgrade is judged on its own. Set a decision date with your security and compliance owners, and record the rollback point: the 25.04 package or image version and a configuration backup taken before the change. Partner quotes for this work should follow from a written scope that names the environments, the WOPI hosts and the number of servers involved.
What changes in 26.04 and what each change asks of you
This table lists the changes the 26.04 announcement names and what each one asks of your team before rollout. The supplied release facts do not detail breaking changes or deprecations, so confirm those in the full 26.04 release notes before you set a change window.
| Change | Impact | Action needed |
|---|---|---|
| Optional AI assistant in Writer, Calc and Impress | Off by default, so existing editing behavior should not change until an administrator enables it. Once enabled, users in all three editors can reach it. | Decide whether it stays off for the first rollout. If you enable it, pick the provider and confirm whether it is hosted externally or on your own infrastructure. |
| AI provider and hosting choice | Determines where document content may be sent for AI processing, which affects data protection and sovereignty obligations. | Document the provider, hosting location and data flows with your privacy and security owners. Confirm the configuration keys and network paths in the 26.04 documentation. |
| Classification labels | Named as a 26.04 topic. Their behavior, configuration and effect on existing documents should be confirmed before you rely on them. | Ask Collabora for the exact feature scope and setup steps. Test label display and handling with your own document set before enabling for users. |
| Configuration review | Existing 25.04 settings carry over unless the release notes say otherwise, so new options can be missed without a review. | Compare your current configuration with the 26.04 reference, note new options and decide each one explicitly. |
| Breaking changes and deprecations | Not detailed in the supplied release facts. Removed or renamed settings could stop a server from starting or change WOPI behavior. | Read the full 26.04 release notes and list every removed, renamed or changed setting against your configuration before the test cycle. |
| Security updates in the 25.04 line | Collabora publishes advisories for its branches. Staying on 25.04 means relying on point releases such as 25.04.13 for fixes. | Track advisories for your branch and plan the move so that unpatched time on 25.04 stays short. |
Which breaking changes and deprecations to confirm before you start
Start by reading the Collabora Online release notes and the COOL 26.04 announcement on the Collabora forum, then build your own list of changes that touch your installation. The 26.04 announcement is the place to confirm what changed in the branch, but the facts supplied for this page do not list specific breaking changes or removed options, so do not assume there are none. Work through the release notes section by section and record each item that affects your environment. For each one, note the setting, the package or image, and the owner who will test it. Ask Collabora or your support contact to confirm anything the notes leave unclear before the change window is booked.
Check three areas first. Compare your configuration file keys against the 26.04 documentation, paying particular attention to proxy and WOPI settings such as the storage.wopi section and any ssl or net options that your reverse proxy depends on. Review the WOPI allow list, because Nextcloud recommends restricting WOPI requests to the IP addresses of the Collabora servers, and any change to how the host or address is presented can silently break editing. Confirm that the Collabora server URL uses the same protocol as your Nextcloud installation, preferably HTTPS. Record each configuration key you find in use, so you can tell at test time whether a key still exists in 26.04.
Carry the 25.04 security baseline into this plan before you touch 26.04. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. Confirm that your 25.04 servers run at least that point release, that your package manager trusts the updated signing keys, and that your repository configuration points to the right channel. Treat any server still on an older 25.04 point release as a security gap to close first, and record the installed version as the starting point for rollback. Also confirm the latest 25.04 point release available to you, since the notes record point releases continuing into 2026.
Preparation: backups, inventory and a test environment
Most failed upgrades trace back to work skipped before the first package changed. The six items below give you a rollback point, a list of what the upgrade can break, a place to rehearse it, and people ready to check documents. Complete them in order, because the inventory decides what the staging test must prove.
Full backup before any change
Take a copy of the configuration, the proxy and ingress rules, and the server state before you touch a package or image. For a package install, that means coolwsd.xml and anything under /etc/coolwsd, plus the WOPI host settings that point at it. For Kubernetes, export the release values and the current chart version. Store the copy off the server, and test one restore on a scratch host so you know the backup is usable. Write down the exact version you are leaving so rollback has a target.
Inventory of local customizations
List every change made outside the defaults: custom configuration keys, proxy rules, Helm values, Docker run options, certificate paths and file permissions on the document and log directories. Each item is a candidate for breakage, so mark which ones you still need and which were workarounds for problems that no longer exist. Ask the 25.04 release notes and the 26.04 announcement which keys or behaviors changed before you decide what to keep.
Staging environment that mirrors the WOPI host
Build a staging Collabora Online server that matches production in version, TLS setup, proxy path, and the allow list for your WOPI host. Use a copy of your WOPI host, such as Nextcloud, with the same connection settings. A staging server that only opens documents on its own URL will not reveal the protocol mismatches and allow list warnings that appear in production. Confirm that the staging host can reach the Collabora server by the same address your users use.
Signing keys and repository changes
RPM and DEB users need to check repository definitions and package signing keys before the upgrade, because the 25.04 release notes record that signing keys were updated for both package types. Compare the current key fingerprints with the ones published by Collabora, and update the repository entries in staging first. Keep the old key until the new packages install cleanly, and record which repository path each host uses so a failed update does not leave a server pulling from the wrong branch.
Document test corpus
Assemble a fixed set of files that represent your real work: long Writer documents with tracked changes and comments, Calc workbooks with macros disabled and large ranges, Impress decks with embedded media, and PDFs and legacy formats your users still open. Store the originals with checksums so you can repeat the same test after each change. Include documents with restricted or classified labels, since 26.04 adds classification label support and you need to confirm how those files behave.
Testers and their test scripts
Name the groups and individual users who will test, and give each group a short script covering open, edit, save, co-edit, export, and print. Include at least one administrator who can read server logs and one user from each group that the Nextcloud Office settings allow to edit. Ask testers to record the document, the browser, and the time of any failure. A short written list of who signs off on each area makes the go or no-go decision traceable.
How the upgrade differs by deployment method
On package-based installs, the upgrade replaces the installed Collabora Online packages with 26.04 packages from your repository, and the service restarts on the new binaries. Configuration files are usually kept, but a package upgrade can prompt you about changed files or overwrite them, so compare the new defaults with your current settings before accepting any change. Record the exact 25.04 package version you run today, because that version is your rollback target.
- Repository and keys: Confirm the repository points at the 26.04 branch and that your RPM or DEB signing keys are current, since the 25.04 release notes record key updates for both package types.
- Replaced: The coolwsd binaries and the packaged service units change with the new version.
- Preserved: Local configuration, TLS certificate files and document storage sit outside the package and should stay in place. Back up the configuration directory before you start.
- Rollback point: Keep the 25.04 package version available in your repository or local cache so you can reinstall it if 26.04 fails verification.
- Node order: Upgrade and verify one node at a time, checking the service status and logs before you move to the next.
Check that the package manager did not overwrite your edited configuration and that the installed version matches the release you tested.
In a Docker deployment, the upgrade is a change of image tag followed by a container recreate. The container filesystem is replaced, so anything not mounted from the host or passed in as environment variables is lost on recreate. If you run the free CODE image, collabora/code, note that Collabora describes CODE as suited to testing, home use or small teams and not recommended for production, so a production move should also follow the subscription path covered in the sibling topic on moving from CODE.
- Replaced: The image tag and the software inside the container change when the container is recreated.
- Preserved: Configuration mounted from the host, environment variables, network settings and any mounted certificate files persist if your compose file or run command keeps them.
- Rollback point: Keep the 25.04 image tag in your registry and keep the previous compose file or run command, so the rollback is a redeploy of the old tag.
- Pinning: Use an explicit version tag rather than a floating tag, so each deployment states exactly which release is running.
- Document sessions: Recreating the container ends active editing sessions on that host, so schedule the change for a quiet period.
Confirm that the old tag is still pullable from your registry before you start, because a rollback that depends on an image you cannot pull is not a rollback.
On Kubernetes, the Helm chart and the COOL Controller are versioned and upgraded as separate parts of the deployment. The Helm chart README says horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replicas are set manually and load balancers must route by the WOPISrc parameter. Each document has to stay on one pod for its whole session, which is why rolling changes need to be planned around open documents.
- Replaced: Pods move to the new image as the Deployment rolls, and chart values or templates change with the new chart version.
- Preserved: Values files, secrets, ingress definitions and persistent configuration remain if you keep them in version control and apply them unchanged.
- Replica count: Set replicas explicitly for the upgrade window. Autoscaling is not a safety net here, so confirm your capacity before you remove a pod from service.
- Routing: Confirm that your ingress controller routes by WOPISrc, so a pod that is draining does not receive new sessions for documents it already holds.
- Rollback point: Keep the previous Helm release revision and the COOL Controller version in use, so you can roll back the release if the new pods fail verification.
Read the Helm chart README for the exact replica and routing settings in the chart version you plan to deploy, and test the rolling sequence in a non-production cluster first.
The upgrade sequence across servers, with checks and rollback points
This sequence moves Collabora Online from the 25.04 branch to 26.04 one server at a time, so each stage proves the upgrade against your real host before the next one starts. Every step closes with a check and a rollback point, so a failure stays contained to the server or stage where it appeared.
Rehearse the upgrade in staging
Build a staging copy that matches production: the same Collabora Online 25.04 configuration, the same WOPI host version, the same TLS termination and a copy of the production document set. Upgrade the staging server to 26.04 and record the exact package or image versions and every configuration change. The step is done when the rehearsal runs end to end with no unexplained errors in the logs. Take a snapshot of the 25.04 staging server before you start so you have a known rollback point.
Confirm the baseline on production servers
Before touching production, record the state of each server: installed version, active configuration, allow list entries for WOPI hosts, TLS certificate validity, and the list of open test documents. Store the configuration files and the current package signing key status with your change record. The baseline is complete when someone other than the operator has reviewed the record. This is your first rollback point, because you can restore the previous state from these files if needed.
Upgrade a canary server and drain traffic
Pick one production server, ideally one that takes a small share of traffic, and remove it from the load balancer or WOPI host routing. Upgrade it to 26.04 and restore your reviewed configuration, adjusting only the settings the release notes require you to change. Keep the 25.04 backup available until the canary has passed every check in the following steps. The canary stage is complete when the server reports healthy and accepts connections only from your test client.
Verify the canary with the WOPI host
From the WOPI host, open a set of test documents on the canary: a docx, an xlsx, a pptx, an ODF file and a PDF, using both edit and view permissions. Save each document, reload it and confirm that changes persist and that formatting matches the staging baseline. Confirm the WOPI handshake succeeds, that the host's allow list contains the canary's address, and that the connection uses the TLS protocol and certificate you expect. The step passes only when every test document opens, saves and reloads cleanly. If any check fails, return the server to 25.04 from its backup and keep it out of rotation.
Roll the upgrade across remaining servers
Upgrade the remaining servers one at a time, repeating the drain, upgrade, configuration restore and document checks used on the canary. Do not upgrade the next server until the previous one has passed the full set of checks and has served live sessions without errors. Keep a record of each server's version, configuration hash and check results. The stage is complete when every server reports 26.04 and passes the same checks. Pause and roll back any server that fails, because the other servers remain on a known working version.
Run post-upgrade verification across all servers
After the last server is upgraded, run the full document test set against every server through the normal routing path, including documents that are already open in a session when you begin. Check that TLS certificates, allow list entries and access controls match the baseline, and that the Nextcloud or other host administration settings still restrict editing to the intended groups. Review logs for warnings about WOPI allow lists, protocol mismatches or missing fonts. The sequence is complete when the checks pass, the change record is signed off, and the 25.04 backups are retained for the period your own change policy requires.
Testing documents, integrations and rollback before you roll
Test the 26.04 branch against your own documents and your own WOPI host before any production server changes version. Build a fixed test set that covers the formats your users actually open: Microsoft files in docx, xlsx and pptx, OpenDocument files, PDFs, and a small sample of legacy formats such as older Word or Excel files that your archive still holds. For each file, open it in the editor, make a change, save, reopen it in the previous 25.04 server and compare the layout, fonts, tables, charts and comments. Record which file types render differently so users know what to expect. Collabora's format support is described on the Collabora Online product page, but that page does not replace your own fidelity check.
Co-editing and clipboard behavior need their own test cases because they fail in ways a single-user check misses. Have at least three test accounts open the same document at once in Writer, Calc and Impress, then confirm that edits appear for everyone, that cursors and presence indicators update, and that copy and paste between documents and between browser tabs still works. In Nextcloud Office, test the group restrictions your administrators set: one account in the group allowed to edit, one allowed only to view, and one outside both groups. Confirm the 26.04 build still respects those settings, and that the AI assistant stays off for every group until your administrators have decided otherwise. For rollback, keep the 25.04 package or container image and a copy of the configuration files in a location that survives the upgrade. Define go or no-go criteria before the window opens, such as zero failed saves in the test set, working co-editing across the test accounts, and a clean WOPI handshake. If a criterion fails, restore the saved configuration and the previous image, then confirm the test set passes again.
What makes this upgrade take longer
This table lists the factors that expand or shrink the 25.04 to 26.04 move and how to keep each one under control. Read each row as a question to answer about your own estate before you agree a schedule or a fixed scope. The main takeaway is that integrations, custom proxy rules and the AI assistant decision usually matter more than the server count itself.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Number of WOPI hosts and integrations | Each host, such as Nextcloud or another document platform, has its own WOPI host URL, allow list and user permissions that must be retested after the upgrade. | Inventory every host and integration first, then test the most used editing flows on each one in a staging copy. |
| Custom configuration and proxy rules | Local changes to coolwsd settings and reverse proxy routes may not carry over cleanly and can break WOPI paths or WebSocket traffic. | Compare your current configuration with the 26.04 defaults and keep a written list of every deliberate deviation. |
| Number of servers and whether they run as a cluster | Clustered or load-balanced deployments need every node moved in a controlled order, and documents open on a node must stay routed to that node during the change. | Agree a rolling order, drain or hold traffic per node, and confirm WOPISrc-based routing still works after each step. |
| Size and variety of the document corpus | Large files, macros, embedded objects and older Microsoft or OpenDocument files take longer to render and are where fidelity differences show up. | Build a representative test set from real business documents, including the largest and most complex files, and record expected results. |
| Use of the AI assistant (provider choice, hosting location, data handling review) | The assistant is off by default, but enabling it requires choosing a provider, deciding whether processing is external or on your own infrastructure, and reviewing what document content is sent. | Decide early whether the assistant stays off for this release, and if it is enabled, complete the provider and data handling review before testing begins. |
| Number of people who must sign off on testing | Business owners, security, compliance and the integration teams may each need to approve results, and sequential approvals can stretch the schedule. | Name the approvers and their acceptance criteria before testing starts, and run their reviews in parallel where possible. |
Questions teams ask before upgrading Collabora Online to 26.04
What does an upgrade to Collabora Online 26.04 cost?
The cost is set by the written scope, not by a list price. DeployOpen does not publish prices, and the fee follows from the work agreed before it starts. The main drivers are the number of Collabora servers, whether a load balancer or Kubernetes deployment is involved, how many WOPI integrations (such as Nextcloud) must be retested, how much document fidelity testing is required, and whether you need post-upgrade support. Ask for a quote that separates the one-time upgrade work from any recurring retainer. Your software licensing is a separate question: the free CODE edition carries no vendor subscription, while the Business plan is listed by Collabora at 3 euros per user per month for up to 99 users, and that fee is paid to Collabora, not to DeployOpen.
How long does the upgrade take?
Duration depends on what has to be checked, not on the version number alone. The biggest factors are the number of servers to roll, the number of WOPI hosts that must be tested against 26.04, the volume and variety of documents in your test set, and how many change windows your operations team allows. Environments that already run configuration management and a staging copy of their WOPI host usually move faster than those that edit configuration by hand. Ask any partner for a schedule built from your environment and for the specific milestones it covers, including staging, rolling production, and a sign-off window.
What must our team provide before the upgrade starts?
Most delays come from missing inputs rather than from the upgrade itself. Plan to provide:
- Administrative access to the Collabora servers, load balancer or ingress, and the WOPI host (for example, Nextcloud Office settings).
- A current, tested backup of the WOPI host and of the Collabora configuration, plus a documented restore procedure.
- Test accounts in each permission group, including users who can only view and users who can edit.
- A representative set of documents in the formats you actually use, such as docx, xlsx, pptx and PDF.
- A named owner who signs off on test results and the production cutover.
Can our own team perform the upgrade without a partner?
Often yes, if the team already runs the WOPI host and the Collabora servers and has tested upgrades of similar Linux or container services. The work needs skills in Linux package management or container images, reverse proxy and TLS configuration, WOPI host administration, and basic performance testing. It also needs a staging environment that matches production closely enough to catch allow list, protocol or routing problems. Teams without that combination, or without spare capacity during change windows, usually get more value from a fixed-scope engagement that covers testing and rollback planning. Whichever route you choose, read the 26.04 release announcement and your current configuration against it before scheduling work.
Should we turn on the AI assistant when we upgrade?
We recommend upgrading first and enabling the AI assistant separately. Collabora's 26.04 announcement describes the assistant as optional and off by default, with administrators choosing the AI provider and whether that provider is hosted externally or on infrastructure they control. That choice has data protection, cost and access consequences that should be reviewed on their own. Confirm with your compliance team which document content, if any, may leave your environment, which user groups may use the assistant, and how usage will be logged. Keeping it off during the first rollout also makes it easier to tell whether any problem came from the version change or from the new feature.
How do the Business and Enterprise plans affect support during the move?
The plan you hold determines what Collabora itself will support during and after the upgrade. According to Collabora's pricing page, the Business plan for up to 99 users includes 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. Check these entitlements in your contract before the cutover, because they decide who you contact if a fault appears in production. Independent upgrade work, such as testing and rolling the servers, is scoped separately from the vendor subscription.
Do we need to upgrade from CODE to a subscription at the same time?
Not necessarily, but the two decisions should be made together. CODE is the free edition, released roughly once a month as a rolling release, and Collabora describes it as suited to testing, home use or small teams and not recommended for production. If you run CODE in production, the 26.04 upgrade is a natural point to move to a supported subscription, because the repository, image and configuration changes overlap with the upgrade work. Ask for the change plan to be listed as a separate line item so that the subscription decision and the version move can each be approved on their own timeline.
Official sources for the 26.04 upgrade
Start with the Collabora Online 26.04 announcement on the Collabora forum, because it states what the branch adds and what changes by default. The headline addition is an optional AI assistant across Writer, Calc and Impress that is off by default, and administrators choose the AI provider and whether it runs externally or on their own infrastructure. Read it with your change board in mind: any decision to enable the assistant is a data-flow decision, not only a feature switch, so record it as a separate item in the plan. Collabora Online 26.04 announcement is the natural first read.
Next, read the Collabora Online 25.04 release notes against your current configuration. Because you are moving from 25.04, these notes describe the behavior you already run, including the point releases you have applied and the security fix recorded for 25.04.7.5. Confirm which point release is installed on every server, since the upgrade baseline should be the latest 25.04 build, not the original release. Also check the package signing key notes for RPM and DEB users, because an out-of-date key can block the upgrade on a host that was never touched.
Use the Collabora Online release notes index to confirm the 26.04 entries and any point releases published after the announcement, and to check whether a newer build should be your target. For Kubernetes teams, the Collabora Online Helm chart README is the reference for values, ingress options and replica handling. Confirm the chart version and app version in your own environment before you copy any example values, and keep a record of the sources you used so auditors can trace each configuration change to its source.
How DeployOpen scopes, delivers and supports the upgrade
DeployOpen plans and carries out the move from Collabora Online 25.04 to the 26.04 branch inside your own infrastructure, starting with a written scope that names your servers, integrations and test documents. The work is delivered in stages with documented evidence, and ongoing support is available as a retainer once the upgrade is complete.
How we scope
- Engagements are fixed-scope, with the servers, WOPI hosts and deployment method agreed in writing before work starts.
- The written scope lists which 25.04 configuration items are reviewed against the 26.04 release notes and which are left unchanged.
- The scope names the test documents, formats and integration flows that must pass before any production server is changed.
How we build
- We prepare a staging copy of your 25.04 deployment and run the upgrade there first, recording each step as it is performed.
- Optional AI assistant settings are reviewed and kept off unless your written scope and approved provider say otherwise.
- Rolling upgrade steps across your servers are sequenced so that open editing sessions are handled as the written plan describes.
How we hand over
- You receive the updated configuration, a record of changes made, and the results of the agreed document and integration tests.
- A rollback procedure for each server is documented and walked through with your operations team before cutover.
- Runbooks cover how to confirm the running version, check WOPI connectivity and apply later point releases on your schedule.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover is accepted.
- Support scope for later point releases and security advisories is agreed in writing, so you know what is covered.
- Questions about your Collabora Online subscription, including support entitlements, should be confirmed directly with Collabora.
