Upgrading Collabora Online from 24.04 to 25.04: why and when to move
A team running Collabora Online 24.04 servers behind a WOPI host such as Nextcloud should plan the move to the 25.04 branch now, because that branch is the current step on the path from 24.04 and it is still receiving maintenance. According to the Collabora Online 25.04 release notes, the 25.04 branch was first released on June 19, 2025 with 25.04.2.3, and it was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. The timing question is therefore less about whether 25.04 is supported and more about how long your 24.04 servers have been running without the fixes that landed in the later point releases. Before you schedule anything, confirm which exact 24.04 point release each server runs, since that version determines which release notes apply to you.
The supported path is to move within the branch sequence rather than jumping straight to a newer major release without reviewing what changed in between. Your team should read the release notes for every point release between your installed version and the 25.04 target, not only the final one. Security content matters here: 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. A server that stayed on an older 24.04 build may therefore be missing security fixes that a straight install of the latest 25.04 point release would include. The exact step-by-step path, including any intermediate stops and any configuration changes, must be confirmed against the release notes for your installed version before you change a production server.
What changes between 24.04 and 25.04 and what you must do
This table pairs each change recorded for the 25.04 branch with its likely impact on a 24.04 server and the action to take. Work through the rows before scheduling the upgrade, because the signing key update affects package installs regardless of what else you change. The main takeaway is that the supplied release facts cover the signing key and one security fix, so the full release notes remain the source for anything else that could affect your installation.
| Change | Impact on a 24.04 server | Action needed |
|---|---|---|
| RPM and DEB package signing keys updated | Package managers may reject or warn about packages signed with the updated keys if the old key is still trusted on the host | Confirm the new key with Collabora's release notes, update the repository key on each host, and verify package signatures before installing 25.04 packages |
| Security fix in 25.04.7.5 (CVE-2026-23623) | Servers still on earlier 25.04 point releases or on 24.04 lack this fix | Plan to reach at least 25.04.7.5 on the 25.04 branch, and check the advisory scope for your 24.04 servers before the move |
| Full release notes for 25.04 | Breaking changes, deprecations and configuration changes are not covered by the facts used for this page | Read the 25.04 release notes end to end, list every configuration key or behavior change that touches your deployment, and confirm each one in a test environment |
| Point release history on 25.04 | The branch has seen many point releases, including 25.04.13 in September 2026, so the target version changes over time | Pin the exact target point release for the change window and record it in the change request |
| WOPI host behavior with the new build | Document editing flows in the host application may behave differently if the editor version changes | Run integration tests with the WOPI host for opening, editing, saving and locking documents before go-live |
Preparing the 24.04 servers before the upgrade starts
Four groups of material decide how safely the move to 25.04 can be made and reversed. Gather them before any package changes, so the team can rebuild the current state if a test or rollout goes wrong. Each card covers one item the team must hold in hand before the upgrade window opens.
Configuration and server backups
Take a copy of the coolwsd.xml configuration, the systemd unit overrides, and the proxy configuration in front of the server, along with a full image or snapshot of the host. Record the installed package versions with your package manager so you can reinstall the exact 24.04 build if needed. Store the copies outside the host being upgraded and confirm that a restore has been tested on a spare machine. Do not rely on the package manager to roll back configuration files.
Customization inventory
List every local change that the 25.04 packages could overwrite or ignore: custom fonts installed on the host, proxy rules for the WOPI and discovery endpoints, WOPI host allow lists, TLS certificates and any custom loading pages. For each item, note where it lives and who owns it. Fonts and allow lists are the ones teams most often forget, and a missing font shows up only when a user opens a document in a specific language or format.
Test environment that mirrors the WOPI host
Build a non-production copy of the Collabora server and the WOPI host it serves, such as Nextcloud, using the same versions, connection protocol and URLs. The copy should use the same reverse proxy rules and a representative set of documents in the formats your users open. Without this, integration problems with the WOPI host only appear after the production change. Agree in writing who signs off the test results before production is touched.
Package sources and signing keys
Record which repository, image tag or package source each server uses today, including whether it is the free CODE build or a supported subscription. Note the package signing keys that are currently trusted on RPM and DEB systems, because the 25.04 release notes record that these keys were updated. Confirm access to the vendor repository from the upgrade hosts before the window, and keep a record of who holds the subscription credentials.
The upgrade sequence with checks and rollback points
This sequence moves a Collabora Online deployment from the 24.04 branch to 25.04 one step at a time, so every change has a check that must pass and a rollback point that keeps production editing available. It ends with all servers on 25.04 and editing verified from the WOPI host.
Freeze the baseline configuration and versions
Record the exact installed package or image versions on every 24.04 server, copy the active configuration files (coolwsd.xml, the proxy configuration and any service overrides) to a dated location, and note the WOPI host version and its allowed WOPI host settings. Take a snapshot or backup of each virtual machine or of the container host, and confirm that a restore has been tested on at least one server. The output is a written baseline that another engineer could use to rebuild any server exactly as it was. Rollback point: the snapshot and the copied configuration, which are kept until production has run on 25.04 for an agreed period.
Update package signing keys for RPM or DEB
Before changing the Collabora Online package version, update the package signing keys on each server according to the instructions in the 25.04 release notes, which record that signing keys were updated for RPM and DEB users. Confirm the repository source and the key fingerprint against the vendor documentation, then run a metadata refresh and a signature check without installing anything. The output is a package manager that verifies the new repository cleanly on every server. Rollback point: reverting the repository and key files to the copies saved in the baseline step, which restores the 24.04 package source without touching the running service.
Move a test server to 25.04
Choose one non-production server that matches production in operating system, package source and proxy setup, and upgrade it to the 25.04 branch. Review the 25.04 release notes for configuration changes and deprecations, apply any required edits to a copy of the configuration, and restart the service. Check the service status, the discovery endpoint and the admin console logs for startup errors. The output is a test server that starts cleanly on 25.04 with a configuration you have reviewed. Rollback point: reinstalling the 24.04 package version from the saved baseline or restoring the test server snapshot.
Run integration tests from the WOPI host
Point a staging instance of the WOPI host (for example, a Nextcloud test installation) at the upgraded test server and run a defined test set. Include opening, editing and saving documents in each format your users rely on, including docx, xlsx and pptx, plus PDF and any OpenDocument files, and check that concurrent editors on one document see each other's changes. Confirm that WOPI allow list settings, the protocol used for the server URL and the group restrictions on the editor still behave as configured. The output is a written test record with pass or fail for each case. Rollback point: the test server reverts to 24.04 and the staging configuration stays in place, so the same tests can be rerun on the 24.04 server for comparison.
Roll production servers one at a time
Upgrade one production server, drain or stop new sessions on it according to your load balancer's method, and let open documents close or move as your routing allows. Repeat the same reviewed steps on that server and run a short editing check from the WOPI host before moving on. Keep the remaining servers on 24.04 while this one is verified, so at least one known-good server remains in the pool. The output is one upgraded server that passes the same checks as the test server. Rollback point: restore that server from its snapshot and return it to the pool while the others stay on 24.04.
Keep one server on 24.04 until the others pass
Hold the last server on 24.04 until every upgraded server has run through a full working period with the integration tests passing and no new errors in the logs. Confirm with your own monitoring rather than assumptions, and record any warnings about allow lists, protocol mismatches or font problems. The output is a decision, recorded in the change log, to upgrade the final server. Rollback point: the final server remains a complete 24.04 fallback that can be moved back into the pool if the upgraded servers show a fault that the tests did not catch.
Verify editing and close the upgrade
Upgrade the final server, repeat the integration test set against the full pool, and sample real editing sessions from the user groups that use Collabora Online most. Confirm the version on every server matches the 25.04 branch, that the signing key change is in place everywhere and that the baseline and snapshots are archived with the change record. The output is a signed-off upgrade with evidence of every check. Rollback point: until the archive step is complete, the snapshots and saved configuration remain available for restoration.
Testing the WOPI integration before you switch production traffic
An integration test for a 24.04 to 25.04 upgrade has to prove that the WOPI host and the upgraded Collabora Online server still complete the full editing cycle, not just that the server responds. In a Nextcloud deployment, run the test against a staging Nextcloud instance pointed at the 25.04 server and cover open, edit, save and reopen for each format family your users rely on: docx, xlsx and pptx, OpenDocument files such as odt, ods and odp, and PDF. Use documents taken from your own file shares, since templates, embedded objects, fonts and macros in real files are where fidelity problems usually appear. Record which user accounts, which groups and which browsers were used so the results can be repeated after any later change.
Check the access controls as part of the same run. Confirm that the Nextcloud server only accepts WOPI requests from the IP addresses of your Collabora servers, as the Nextcloud administration manual recommends, and that the Collabora server URL uses the same protocol as the Nextcloud installation, preferably HTTPS. Then confirm the group settings in Nextcloud Office: a user outside the permitted editing groups should be able to view a document but not edit it, and a user outside the editor groups should not open the editor at all. Test these from accounts that really belong to each group, because a misconfigured allow list often fails silently for users who are not administrators.
Treat every failed step as a blocker for the cutover and keep a written log of the results alongside the rollback plan. Confirm the exact 25.04 point release you are testing against in the Collabora Online 25.04 release notes, since the branch receives regular point releases, and rerun the suite if the server is updated before go-live. The expected outcomes for your own documents and environment should be agreed with the document owners in advance, because DeployOpen and the vendor documentation can describe the general behavior but cannot confirm fidelity for your files.
Rollback options if 25.04 fails in your environment
A server that fails its integration tests before it takes live traffic is the easiest rollback, because no users have depended on it yet. The usual action is to stop the 25.04 service on that node, reinstall or restore the 24.04 packages from the version you pinned, and put the node back out of the load balancer pool until the tests pass. Keep the original configuration files in a dated copy before you begin, so you can compare what the upgrade changed.
- Snapshot before upgrading: Record the installed package version, copy
/etc/coolwsd/and any proxy configuration, and note the Nextcloud or other WOPI host settings that point to this node. - Pin the previous branch: Reinstall the 24.04 packages from your local mirror rather than pulling whatever the repository currently serves, so the rollback matches what you tested before.
- Confirm the signing key state: Check that the 24.04 package signature verification still works after you restore, since the 25.04 release notes describe updated RPM and DEB signing keys.
- Re-run the WOPI test: Open a document through the restored node from the WOPI host, then edit, save and reopen it to confirm the old branch behaves as expected.
- Document the decision: Record which test failed, the version you returned to, and the time the node left the pool.
Before relying on this path, confirm with your package source that the 24.04 packages remain available in your mirror and that your pinned version still resolves for your distribution.
A fault that appears only after production traffic moves to 25.04 is harder to roll back, because users may have opened documents, saved edits and left sessions open on the new branch. Rolling back the software is still possible, but you must plan for active editing sessions, documents saved by the new server, and any configuration you changed during the upgrade. Decide in advance who can authorize a rollback and what the user-facing message will say.
- Drain before reverting: Remove the upgraded nodes from new session routing, and let open sessions close or move according to your change plan, so no document is left split between versions.
- Restore configuration: Return the saved configuration copy to the nodes you revert, and check any settings you deliberately changed for 25.04, such as proxy endpoints or WOPI allow lists.
- Check document integrity: Ask a sample of users to confirm recent edits, and compare saved files against your backups, because the file store is not part of the Collabora package.
- Coordinate with the WOPI host: Confirm that the host's stored state and any cached editor URLs still match the restored server before you announce the rollback.
- Record the window: Note the time traffic moved and the time it returned, so support can identify documents edited during that period.
Before you start, confirm with your package source which 24.04 package versions remain available, and confirm with your own backup team that the file store backup covers the period in question.
An urgent security advisory can force a change outside your planned window, and that may be the reason you are on 25.04 in the first place. Collabora publishes advisories for Collabora Online, and the 25.04 release notes record a fix in point release 25.04.7.5 (CVE-2026-23623). Your rollback decision should separate two questions: whether the advisory applies to the version you are running, and whether reverting to 24.04 would leave you more exposed, which it can, because older branches may not receive the same fixes.
- Check the advisory against your version: Compare the exact installed version with the fixed release named in the advisory before deciding that a rollback is needed.
- Prefer a point release over a branch change: Where the fix exists on 25.04, apply the point release first, since it avoids a second change in the same window.
- Confirm support for the old branch: Ask Collabora whether 24.04 still receives signed security updates for your package type, and do not assume it does.
- Restore signing trust: If you move packages, verify the signing key before installation, using the key updates described in the release notes.
- Log the exception: Record the advisory ID, the decision, the compensating controls, such as restricting WOPI requests to known host addresses, and the review date.
Before relying on any rollback in this situation, confirm with your package source and with Collabora's security communications which versions carry the fix and which are still supported.
Every rollback depends on whether you can return both the software and the state it was serving. This tab covers the parts that sit outside the Collabora packages, which are often the reason a rollback takes longer than expected. Treat configuration, WOPI host settings and document storage as separate restore targets, and test each one before you need it.
- Configuration copies: Keep a versioned copy of the Collabora configuration and the reverse proxy settings from before the upgrade, and store it where the rollback team can reach it during an incident.
- WOPI host settings: Record the Nextcloud or other host configuration that points to the Collabora server URL, including the protocol, so you can reverse any change made for the new branch.
- Document backups: Confirm that your backup of the document store covers files edited on 25.04, and know the restore point you would use if edits must be discarded.
- Container images or package pins: If you run Docker or Kubernetes, keep the previous image tag or chart version recorded, and confirm it is still pullable from your registry.
- Test the restore: Run one restore into a non-production environment before the change window, and time it, so the decision uses real data rather than assumptions.
Before relying on these restore points, confirm with your backup owner and your package or image source that the older artifacts are retained for the period you need.
What makes a 24.04 to 25.04 upgrade longer or shorter
This table compares the factors that push the effort of a 24.04 to 25.04 upgrade up or down, and the direction each one moves the work. Read each row against your own fleet to see which factors dominate your plan. The main takeaway is that fleet size, custom proxy rules and the number of WOPI hosts tend to matter more than the version step itself.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of servers and deployment model | Each Linux package, Docker or Kubernetes node is a separate upgrade and rollback unit. Pushes effort up with count and with manual per-server steps. | Standardize hosts with one repeatable procedure and stage the upgrade on a single representative server first. |
| Kubernetes or package model | Helm-based rollouts move open documents during pod restarts and need replica handling. Package installs depend on distribution repositories and signing keys. | Confirm the chart and image versions you will run, and plan restarts in a window where editing load is low. |
| Count of WOPI hosts | Each host (for example Nextcloud or another platform) needs its own integration check against the new server. Pushes effort up with each host added. | Test the hosts that carry the most documents first and reuse one checklist across them. |
| Document formats tested | Office, OpenDocument, PDF and legacy formats each need fidelity checks. A wider format list means more test documents and more reviewers. | Limit the matrix to the formats your users actually open and save, and keep a fixed sample set. |
| Custom configuration and proxy rules | Custom WOPI allow lists, TLS settings, reverse proxy headers and WOPISrc-based routing must be reviewed against the 25.04 release notes. Pushes effort up with each divergence from defaults. | Keep configuration in version control, diff it against a default 25.04 file and document every local change. |
| Signing key handling across fleets | RPM and DEB repositories received updated package signing keys in the 25.04 line. Each server needs the new key trusted, and mismatched keys stop package installs. | Import and verify the new keys on one host, then roll the change out with the same automation used for packages. |
| Size of the integration test matrix | The number of hosts, formats, users and editing scenarios multiplies test cases. Concurrent co-editing and copy and paste across pods are often the slowest to verify. | Define pass and fail criteria before testing and automate the repeatable checks. |
| Rollback readiness | A rollback needs preserved configuration, package versions and a tested path back. Missing backups extend the window in which a fault must be resolved. | Record the current package versions and configuration before the change and rehearse the rollback on staging. |
Questions teams ask before upgrading Collabora Online to 25.04
What does an upgrade from 24.04 to 25.04 cost?
The cost is mostly labor, and it depends on how much of the work your team already carries. Your team pays for staff time to review the 25.04 release notes, update package sources and signing keys, run integration tests against your WOPI host, and prepare a rollback. If you use a partner, the fee follows from a written scope that lists the servers, WOPI hosts, document types and environments involved. Ask each quote to separate one-time work (testing, runbooks, first rollout) from recurring work (point releases, monitoring, support). If you buy a supported subscription, the Business plan is listed at 3 euros per user per month for up to 99 users, according to the Collabora pricing page, and that fee recurs. Confirm with Collabora whether any upgrade work is covered by your plan.
How long does a Collabora Online upgrade take?
The timeline depends on the number of servers, how many WOPI integrations you run, how many document types your users rely on, and whether you have a staging environment that matches production. Most of the elapsed time usually goes into integration testing and into agreeing on a go or no-go decision with the business owners of each integration. Plan for a test window in which your team opens real documents from each host, checks editing, saving, co-authoring and exports, and records any differences. A simple single-server setup with one host will move faster than a multi-server cluster behind a load balancer. Ask any partner to state the duration as part of the fixed scope, along with the dates on which testing starts and ends.
What must our team provide before the upgrade starts?
Your team needs to provide access and information before any change is made. The list usually includes:
- Inventory of every Collabora Online server, its package or container version, and its configuration file
- Access to the WOPI host (for example Nextcloud), including admin rights and a non-production copy
- A list of the WOPI hosts, document formats and user groups that rely on the service
- Test documents that reflect your real content, such as docx, xlsx, pptx and PDF files
- Change windows, a named approver, and a contact for each integration owner
- Backup and restore procedures for the host and its configuration
Confirm these items in the written scope so that testing does not stall when a dependency is missing.
Can our in-house team upgrade Collabora Online without a partner?
Yes, a team with Linux administration experience and access to a staging environment can perform the upgrade in-house. The work sits in three areas: reading the 25.04 release notes and applying any configuration changes, updating package repositories and signing keys for RPM or DEB installs, and running integration tests with the WOPI host. The areas that tend to need outside help are repeatable test cases across several integrations, a rollback plan that has been rehearsed, and documentation for auditors or other teams. Before you decide, confirm the operating system, install method and host versions with your own environment, and check the official release notes for any step that depends on them.
Does running CODE instead of a subscription change the upgrade path?
It does. 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. A production deployment that stays on CODE will follow a different update cadence and will not carry the same support commitments as a subscription. If you plan to move from CODE to a supported subscription, plan that switch as its own step: change the repository or image, carry the configuration over, and confirm your support entitlement before the 25.04 testing begins. Doing both changes in one window makes it harder to tell which change caused a problem.
How should we handle a security fix during the 25.04 upgrade?
Treat a security fix as a separate change with its own short test cycle, and do not wait for the full branch upgrade. Collabora publishes security advisories for Collabora Online. For example, 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. If you stay on 25.04, apply point releases as they arrive and confirm the signing key on each package source. Confirm with Collabora which point release carries each fix, and record the version in your change log so that auditors and security teams can trace it.
What is the rollback plan if the 25.04 upgrade fails?
A rollback plan should describe how to return to the 24.04 package or image, the configuration files it needs, and the data that must be restored. Keep a copy of the working configuration and the package version, and test the restore on staging before the production change. Also decide the rollback trigger in advance, such as failed document opens, broken co-authoring or save errors in any integration. Agree on who makes the call and how long the team waits before rolling back. Confirm the exact package and image versions with your own environment, since the steps differ between installs.
How DeployOpen scopes the upgrade in writing
The upgrade from the 24.04 branch to 25.04 is agreed as a fixed-scope engagement, and the written scope is the document that defines what DeployOpen will change, test and hand over. Before any work starts, the scope names the servers and integrations in play (for example, the Nextcloud Office or other WOPI host connections, the reverse proxy in front of Collabora Online, and whether the installation uses Linux packages, Docker or Kubernetes). It also states which release notes apply, how package signing key updates will be handled on RPM or DEB hosts, and the acceptance tests that count as done. Deliverables and timelines are written against those items, so a quote follows from the scope rather than from an estimate of hours.
To make that scope accurate, the client provides an inventory and test artifacts. The inventory should list every host and container running Collabora Online, the installed package or image versions, the coolwsd.xml settings that have been changed from defaults, the allowed WOPI host entries, and the TLS and proxy configuration. Test artifacts are a set of representative documents in the formats your users actually edit, such as docx, xlsx, pptx and PDF, with expected results recorded. Ask the vendor or your own team to confirm the exact 25.04 point release that will be the target, since the 25.04 release notes list point releases that change over time.
At the end, the handover package records what changed and how to repeat it. Expect a written change record per server, the final configuration with the reasons for each change, the results of the integration tests against the WOPI host, the rollback procedure that was rehearsed, and a list of open items with owners. Confirm in writing whether support after handover is covered by a separate retainer, since ongoing support is offered as a retainer and is not part of a one-time upgrade by default.
How DeployOpen delivers and supports Collabora Online upgrades
DeployOpen plans the move from the 24.04 branch to 25.04 as a fixed-scope piece of work, with the release notes, package signing changes and WOPI host tests agreed in writing before the servers are touched. The same written scope covers rollback planning, documentation and handover to your team, with ongoing support available as a retainer.
How we scope
- We inventory every 24.04 server, its install method (packages, Docker or Kubernetes) and each WOPI host connected to it.
- We review the 25.04 release notes against your configuration and list the settings that need changes or checks.
- The written scope names the environments, WOPI hosts, documents and deliverables covered, and what is excluded, before work starts.
How we build
- We stage the upgrade in a non-production environment that mirrors your ingress, WOPISrc routing and allow list settings.
- We update the package signing keys for RPM or DEB installations and confirm repository access before any package change.
- We run integration tests from your WOPI host (for example Nextcloud Office) covering opening, editing, saving and permissions for representative documents.
How we hand over
- We document the upgrade steps, configuration changes, test results and the rollback procedure for your operations team.
- We record the exact rollback point for each server, including package versions and configuration backups, so reversal is a planned action.
- We walk your team through the findings and open items, and confirm who owns each follow-up after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for teams that want help with later branch moves.
- Point releases in the 25.04 branch can be planned into the same maintenance process so patches are tested before they reach production.
- Ask us to confirm support timing and entitlements for your installation before you commit, since these depend on your current Collabora arrangement.
