How to plan a Collabora Online upgrade before the next branch ships
If you run a Collabora Online branch in production and it is getting older, the right time to move is set by two things: how long your current branch still receives security and point releases, and whether your WOPI host, such as Nextcloud, can be matched to the target version in a planned window. The calendar alone should not decide it. Collabora's public lifecycle model gives each major version about three years of support, ships monthly minor releases, and produces a new major roughly every six months, so the question is which branch you will be on when support ends, not which branch is newest. Confirm the current support period for your branch against Collabora's release notes and pricing page before you set any dates, because these figures can change.
Point releases matter more than major releases for day-to-day risk. A branch that still receives signed security fixes is a different position from one that has gone quiet, and the 25.04 release notes show why this matters: a point release in early 2026 fixed a CVE and rotated package signing keys for RPM and DEB users. Build a short inventory before you plan: the exact branch and point release on each server, the package source (CODE image, distribution package or subscription repository), the WOPI hosts pointed at it, and the owner who approves changes. Then decide whether you will track minor releases closely or hold on a chosen point release for a fixed window, and write that policy down.
Decide whether to step through each intermediate major or skip one. Skipping can shorten the work, but it means more changes at once in configuration, integrations and document rendering, and it leaves less time for a rollback if a WOPI host behaves differently. Whichever path you choose, the later sections of this page cover the supported path from CODE to a subscription, the branch-to-branch upgrades and the upgrade of older loolwsd installations. For each candidate path, ask Collabora to confirm which branches your subscription covers, and plan a staging environment that matches production closely enough to test real documents before the next branch ships.
What changes between branches and what each change asks of your team
This table compares the branch-level changes Collabora has announced or published for 25.04 and 26.04 and maps each one to the work it creates for your team. Read each row as a question: does this change affect our servers, our configuration, our documents or our integrations, and what do we need to confirm before we move.
| Change | Impact on your deployment | Action needed and what to confirm with Collabora |
|---|---|---|
| 25.04 branch availability | The 25.04 branch was first released on June 19, 2025 (25.04.2.3) and was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. | Confirm the current point release and support end date for your edition with Collabora before setting a timeline. Track point releases on the release notes page. |
| 26.04 announcement | Collabora Online 26.04 was announced on July 23, 2026, with new features including classification labels and an optional AI assistant across Writer, Calc and Impress. | Review the release post and release notes against your integrations. Confirm which features your WOPI host can use and whether 26.04 is the branch you will run in production. |
| Optional AI assistant (26.04) | The assistant is off by default. Enabling it requires an AI provider choice, and administrators decide whether the provider is hosted externally or on their own infrastructure. | Keep it disabled until data flow, provider terms and document access are reviewed. Ask Collabora which provider options are supported and what data leaves your network when each is used. |
| Security fix in 25.04.7.5 | Release 25.04.7.5, dated January 29, 2026, fixed CVE-2026-23623. Running an older 25.04 point release leaves that vulnerability in place. | Confirm the fixed version for your branch and schedule the point release. Check the advisory and release notes to see whether your installed build is affected. |
| Package signing key updates | The 25.04 release notes record updated signing keys for RPM and DEB packages. Package managers may reject updates if the old key is still trusted. | Import the new keys from Collabora's published instructions before updating. Test signature verification on a staging host and confirm the key fingerprints with Collabora. |
| Monthly minor releases | Minor and point releases are frequent, so a branch can change several times in a year. Each one carries the risk of a config or behavior change that needs review. | Set a patch window and a test document set for each release. Ask Collabora what each point release changes and whether any configuration keys are deprecated. |
What to inventory and back up before touching the server
Most failed Collabora Online upgrades trace back to details nobody wrote down: a WOPI allow list copied from memory, a proof key nobody can find, or a font that existed only on one server. The cards below cover the records and copies to create before changing any version, and they feed directly into the branch and skip decisions that follow.
Back up the current configuration
Copy the active server configuration file and any drop-in overrides from the existing installation before the package or image changes. Store the copy outside the host so it survives a failed package transaction. Record the Collabora Online version currently running, because the rollback plan depends on it. Confirm which configuration keys were edited by hand and which came from defaults, since defaults may change between branches.
Record the WOPI allow list
Export the list of WOPI host addresses and domains the server currently accepts, and note every entry that exists only because of a past integration. Compare it with the Nextcloud administration guidance on restricting WOPI requests to the Collabora server addresses. A missing entry after upgrade produces connection failures that look like a network fault, so this list is the first thing to verify in the test environment.
Document the WOPISrc and proof key setup
Write down how the WOPISrc parameter is routed through the reverse proxy or load balancer, the TLS protocol used between host and server, and where the proof key pair is stored and who holds it. If the server runs in a cluster, record which node or pod owns each open document. Proof key rotation is a common source of post-upgrade errors, so confirm the key files and their permissions are included in the backup.
List fonts, plugins and host integrations
Inventory every custom font installed on the server, every plugin or extension that changes document behavior, and the version of each WOPI host integration in use. In Nextcloud, read the Office app version and the connected server address from the admin settings page. Missing fonts change pagination in documents that users have already reviewed, so this list also guides file format testing after the upgrade.
Build a test environment at the host version
Stand up a separate Collabora Online server and a copy of the WOPI host at the same version the production host runs, with a copy of the configuration and allow list. Use it to open a representative set of documents, edit them, and test save and co-authoring before any production change. The test server should match the target branch you plan to move to, so the results reflect the version you will actually run.
Confirm the source of the packages
Record whether the current install comes from CODE, a supported subscription, a distribution package, or a container image, and which repository or image tag it tracks. Confirm which signing keys the package manager trusts, since signing key updates have been part of recent Collabora release notes. This record tells you whether the upgrade is a branch move, a source change, or both, and it determines who you must contact for support entitlements.
Which upgrade path is supported and when to skip a branch
Plan upgrades around the branch you run, not the latest release. Collabora supports each major branch for about three years, ships monthly minor releases inside it, and publishes a new major roughly every six months. The 25.04 branch shows the pattern: it was first released on June 19, 2025, was still receiving point releases in 2026, and reached 25.04.13 on September 21, 2026, while 26.04 was announced on July 23, 2026. Because each branch stays supported for years, the default path is one branch at a time, with a point release applied on the current branch first so the baseline is clean before you move. Confirm the exact end-of-support date for your branch in writing with Collabora before you set a schedule.
Skipping a branch is a deliberate choice, not a default. It makes sense when your current branch is close to its end of support and you cannot move to the next branch in time, or when the next branch is itself late in its window and a newer one is already the stable target. Skipping shortens the number of upgrade rounds, but it stacks configuration changes, file permission checks and WOPI host regression testing into one window. Before you choose, ask Collabora to confirm in writing the supported-from and supported-to path for your version, and check that your WOPI host, such as Nextcloud, is supported on the target branch. Record the decision, the test evidence and the rollback point in the change ticket.
CODE and a supported subscription follow different rules. CODE, the free Collabora Online Development Edition, is a rolling release published on average once a month, and Collabora does not recommend it for production. A production estate on CODE therefore has no supported branch to plan against, which is the main reason to move to a supported subscription before you plan any major jump. The Collabora Online pricing page describes 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. Verify those entitlements and their coverage for your branch in the quote, since they determine which upgrade path you are actually supported on.
How to sequence the upgrade with checks and rollback points
The sequence moves Collabora Online from freeze to monitored production one server at a time, with a verification check and a rollback point at every stage so a bad change never reaches all users at once.
Freeze configuration and integration changes
Stop unrelated changes to the Collabora Online servers, the WOPI host (for example Nextcloud) and the reverse proxy for the duration of the upgrade window. Record the current Collabora Online version, the package or image source, the WOPI host version and the list of servers in the pool. Name one owner who approves each later step. The step is done when the change freeze is announced and the baseline inventory is written down, so anyone can see what the starting state was.
Back up configuration and confirm restore path
Back up the Collabora Online configuration files, the WOPI host configuration, the proxy configuration and any certificates or keys in use. Keep the backup in a location that survives a failed server rebuild. Then test that the backup can be read and restored on a scratch host. This backup is the basis of every rollback in this sequence: if it is incomplete or untested, the later rollback points do not hold. The step closes when a restore test has succeeded and the backup location and date are recorded.
Upgrade a staging server first
Apply the target branch update to one staging Collabora Online server that is connected to a staging WOPI host with realistic configuration. Review the release notes for the target branch before the change, including any configuration keys that changed or were removed. Check the service starts, the discovery endpoint responds and the server log shows no errors on startup. Rollback point: reinstall the previous package or image version and restore the backed up configuration. The step is done when the staging server starts cleanly on the new version.
Test documents and WOPI integration on staging
Open a set of representative test documents in Writer, Calc and Impress through the staging WOPI host, including Microsoft formats (docx, xlsx, pptx), OpenDocument files and PDFs. Test co-editing between two accounts, saving, version history, copy and paste, and the permission model you use (view versus edit groups). Confirm the WOPI host allow list and the protocol used for the server URL still match the WOPI host configuration. The rollback point is the staging snapshot taken before the change. The step is done when every test case passes or each failure has a documented decision to proceed or stop.
Roll production one server at a time
Drain new sessions from the first production server at the load balancer while preserving routing by WOPISrc, so users with open documents stay on their current server until those sessions end. Check the count of open sessions on that server, upgrade it, then verify startup, discovery and a test document open before returning it to the pool. Repeat for each server in turn. Do not upgrade the next server until the previous one has passed. Rollback point: each server keeps its pre-upgrade package or image until the whole pool is verified. The step is done when every server reports the target version and passes the test document check.
Monitor errors, sessions and user reports
After the last server is upgraded, watch the Collabora Online logs, the WOPI host logs and the proxy error rates for the monitoring window agreed before the change. Compare session counts and failed document opens with the baseline recorded in the first step. Collect user reports through the support channel and check each one against the logs. If error rates rise or a document class fails repeatedly, use the per-server rollback point to revert the affected server, not the whole pool first. The step is done when the agreed monitoring window closes with no open defects and the change record is signed off.
Confirm rollback depends on the preparation backup
Every rollback point above assumes the configuration backup from the preparation step was taken and tested. Without that backup, reverting a server means rebuilding its configuration from memory, the release notes and the WOPI host settings, which is slower and more error-prone. Confirm, before the freeze ends, that the backup exists, that the restore test passed and that the person who will perform any rollback has access to it. The check is complete when the rollback owner confirms this in writing as part of the change record.
What makes a Collabora Online upgrade take longer
This table lists the factors that most often extend a Collabora Online upgrade, what each one adds to the work, and what to ask a partner to scope. Read each row against your own estate to see which factors apply and where the effort will concentrate before you request a quote.
| Driver | What it adds | What to ask a partner to scope |
|---|---|---|
| Number of Collabora servers | Each server needs its own package or image change, configuration check and restart, and rolling order must keep open sessions working. | How many servers are in scope, whether they run as one group or separate nodes, and the order and window for rolling the change. |
| Load balancer routing by WOPISrc | Upgrading a pool that routes by WOPISrc means draining and restarting nodes without splitting users on one document across pods. | How the balancer is configured, whether session affinity is tested during the upgrade, and how a node is taken out of rotation safely. |
| Number of WOPI hosts and integrations | Each host, such as Nextcloud or another document platform, has its own discovery, allow list and protocol settings to retest after the change. | The list of hosts, their versions, who owns each integration, and which test cases must pass on each one. |
| Custom fonts and configuration | Custom fonts, font packages and local overrides must be checked against the new branch, and some settings may have changed names or defaults. | An inventory of font files, configuration overrides and custom templates, and whether a review of release notes for each target branch is included. |
| Document types in use | Office formats, PDF, CSV and legacy files each carry different fidelity risks, so a wider mix of formats means a larger test set. | Which formats are used most, which templates or macro-bearing files are business critical, and how fidelity will be compared before and after. |
| AI assistant decision | Enabling the optional AI assistant introduced in 26.04 adds provider choice, hosting location, access policy and data handling review on top of the upgrade. | Whether the assistant stays off at go-live, which provider and hosting model are approved, and who signs off the data flows. |
| Staging environment | Without a staging copy that mirrors the production WOPI host and documents, testing moves into production and rollback becomes harder to plan. | Whether a staging environment exists or must be built, how production data is handled in test, and how a rollback is rehearsed. |
| Support model and release cadence | Monthly minor releases and a three-year support window per major mean repeated patching cycles, and the timing depends on the subscription and change control in place. | The patch cadence agreed in advance, which branch is the target, and how point releases are validated before each change. |
What buyers ask before upgrading Collabora Online
What does a Collabora Online upgrade cost?
The cost depends on the scope agreed in writing, and the main drivers are the number of server instances, the WOPI hosts and integrations you must test, any custom configuration, and how far your current installation is behind. Costs fall into one-time work (planning, configuration review, test plan, staged rollout and rollback preparation) and recurring costs (a software subscription if you move to Business or Enterprise, and any support retainer). Software licensing and services are separate line items. DeployOpen does not publish prices, and a quote follows from the written scope. Ask for each phase to be listed separately, the number of environments, which integrations are tested, and whether rollback is included. Confirm current subscription terms with Collabora.
How long does a Collabora Online upgrade take?
Duration depends on how many servers, WOPI hosts and document types need testing, and on how much change control your organization requires before production work. Collabora publishes monthly minor releases and six-monthly major branches, so the target version and the number of point releases between your current version and the target both affect the work. For example, the 25.04 branch was first released on June 19, 2025, and was still receiving point releases, with 25.04.13 released on September 21, 2026. No standard duration is supplied here, so ask for a timeline in the written scope that shows staging, integration tests, a pilot group, the production window and the rollback check.
What does an upgrade need from our internal team?
An upgrade needs named people for a few specific roles, even when a partner does most of the technical work. Typically this includes:
- An owner for the WOPI host, such as the Nextcloud administrator, who can run the integration tests and sign off on editing behavior
- Someone with access to the reverse proxy, DNS and the TLS certificates for the Collabora server URL
- Users or testers who can supply representative documents in docx, xlsx, pptx, ODF and PDF formats
- A change window and an approver who can accept a short editing outage or a rolling restart
- Access to the current configuration, logs and the package or image source used for the installation
Ask the quote to name these roles and state when each person is needed.
Can our own team upgrade Collabora Online without a partner?
Yes, a capable team can upgrade a single server in-house if it has Linux package or container experience, a staging copy of production, and time to test documents against its WOPI host. The work gets harder with multiple servers, a Kubernetes deployment or strict change control. The Collabora Online Helm chart README says horizontal pod autoscaling is disabled and replicas are set manually, and that load balancers must route by the WOPISrc parameter so users editing one document reach the same pod. A rolling restart therefore moves open documents, so the routing and restart order must be planned before the first pod is replaced. A partner is most useful where these routing rules, the rollback plan and the integration tests all interact.
Should we skip a Collabora Online branch during an upgrade?
Skipping a branch is a decision to weigh against support status and the changes you would miss, and it should not be a default. Collabora describes three-year support per major version, so check with Collabora which branches still receive signed fixes on the day you plan. Security fixes matter here. The 25.04 release notes record that 25.04.7.5, released on January 29, 2026, fixed CVE-2026-23623 and updated the package signing keys for RPM and DEB users, so a skipped point release can leave a gap in key handling as well as in code. Read the release notes for every branch between your version and the target, and skip only when the target is supported and your tests cover the changes in between.
What does a Business or Enterprise subscription add to an upgrade?
The Business plan costs 3 euros per user per month for up to 99 users, according to the Collabora pricing page. It 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. Subscription fees recur monthly per user, while upgrade services are usually one-time work. Support matters during upgrades because signed updates and a support route reduce the time spent deciding whether a fix is trustworthy. Confirm current terms, user counts and what each plan includes on the Collabora pricing page before budgeting.
Why must CODE move to a supported edition before production?
CODE, the Collabora Online Development Edition, is the free edition. It is released on average once a month as a rolling release, and Collabora describes it as suited to testing, home use or small teams but not recommended for production. A move from CODE to a supported subscription changes the repository or image source, carries configuration across, and sets up support entitlements, so it should be planned as its own step with a test run. Ask for the switch to be scheduled against your upgrade window, with a clear check that the configuration, certificates and WOPI allow list still work after the change. Use the CODE page to confirm what the free edition is intended for before you decide.
Which Nextcloud settings must stay in place during an upgrade?
Keep the WOPI request restrictions and protocol settings in place, and confirm them again after each upgrade. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, and using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Nextcloud Office also lets administrators limit which groups can use the editor and which groups can edit rather than only view. A new Collabora server address, a changed load balancer or a new proxy path can break these settings silently, so include a check of the allow list, the server URL and the group limits in the upgrade test plan. Confirm the exact settings against the Nextcloud Office configuration guide for your Nextcloud version.
Where to confirm lifecycle dates and release changes
Confirm current branch dates and support terms against Collabora's own publications before you fix an upgrade plan, because lifecycle dates move with each release and a plan built on last year's notice will drift. Start with the Collabora Online release notes, which list each branch and its point releases, then read the release notes for the branch you are leaving and the branch you are targeting. Record the date of the most recent point release on each branch, since that tells you how much security patching the branch is still receiving when your change window opens.
The forum announcement for the 26.04 branch is the place to check what changed in a new major release, including features that are off by default and settings that may need a decision before you enable them. Read it alongside the 25.04 release notes, which document the package signing key updates and security fixes that affect RPM and DEB installs. Ask Collabora to confirm in writing which key or repository changes apply to your package source, and verify the signing key fingerprints from a trusted channel rather than from a copied command.
Check the Collabora Online pricing page for the support terms that apply to your user count, including long term support, service level agreement language and customer portal access. Those terms decide whether a branch you run in production has a defined support window, so ask your account contact to state the end of support date for each branch in your quote. Keep a dated record of what you confirmed, from which source and on what day, and repeat the check before each change window.
How DeployOpen scopes, delivers and supports a Collabora Online upgrade
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes Collabora Online lifecycle and upgrade planning. We start from a written scope that sets the branch path, the environments and the evidence you receive, so the upgrade is agreed before any server changes.
How we scope
- We confirm your current Collabora Online version, install method and whether you run CODE or a supported subscription.
- We record which WOPI hosts, such as Nextcloud, use your server and which document types your users rely on.
- Engagements are fixed-scope, so the written scope names the branches covered, environments, test cases and deliverables before work starts.
How we build
- We build a staging copy of your production setup and run the upgrade there first, including a rollback path.
- We test documents from your own archive in each supported format against the new release and log every rendering difference.
- We apply monthly minor releases and security updates in a planned window, with changes recorded in the change log for each step.
How we hand over
- You receive a written upgrade record covering versions, configuration changes, test results and the rollback procedure used.
- We document the support lifecycle dates for your branch so your team can plan the next major move ahead of end of support.
- We walk your operations team through the update routine, including how to check release notes and advisories before each update.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing like the original engagement.
- A retainer can cover monthly minor release reviews, security advisory triage and planning for each six-monthly major release.
- Ask any provider, including us, to confirm the exact support terms and entitlements for your chosen subscription before signing.
