Why a production team moves from CODE to a subscription
If your users edit documents in Nextcloud or another WOPI host and the Collabora Online server behind them runs the free CODE build, the move to a supported subscription is about risk ownership before it is about features. Collabora describes CODE (Collabora Online Development Edition) as a rolling release released on average once a month, suited to testing, home use or small teams, and not recommended for production. A production team that stays on CODE has no contractual support path, no long term support branch to stay on, and no service level agreement to hold a vendor to when an editing outage hits the people who depend on it.
The supported path is the Business plan, which Collabora's pricing page lists at 3 euros per user per month for up to 99 users, or the Enterprise plan for 100 or more users, which is quoted. Both include the customer portal, and the pricing page says Business adds long term support, a service level agreement and signed security updates. Confirm with Collabora which entitlements apply to your user count and deployment type, and get the terms in writing before you plan dates, since the subscription changes what you can rely on, not just what you pay.
The move is a planned cutover, not a package swap. You will need to change the repository or image source for your installation method, carry configuration across, retest the WOPI integration with your host (for Nextcloud, the Nextcloud Office settings, allow lists and protocol used for the server URL), and agree a rollback path before any user is moved. Each of those steps touches documents that people are editing, so schedule the change with your application owners, record the current version and configuration as a baseline, and treat the first production day on the subscription build as a monitored event.
Business or Enterprise: which plan fits your user count
The Business plan is priced per user, at 3 euros per user per month according to the Collabora Online pricing page, and is aimed at deployments of up to 99 users. Collabora lists it as including long term support, a service level agreement, signed security updates and customer portal access, so the cutover plan should be built around those entitlements rather than around the free build.
- Per-user cost: The published rate is per user per month, so your cost scales with the number of people who edit documents, not with the number of servers.
- Long term support and signed updates: Confirm which branches are covered and how long each one is supported, since this determines when you must upgrade.
- Service level agreement: Ask for the written response targets and how they apply to production incidents raised by your team.
- Customer portal access: Your administrators should receive portal accounts before cutover so that patches, advisories and tickets are handled through one channel.
- Who opens tickets: Confirm which named contacts on your side may raise support requests, and whether your WOPI host vendor must be involved in joint troubleshooting.
Before you decide, confirm the current per-user terms, the user count definition and the exact entitlements on the pricing page and with Collabora in writing.
The Enterprise plan applies to 100 or more users and is quoted rather than listed, with volume discounts according to the Collabora Online pricing page. It adds integration support, customization services and roadmap input on top of the Business entitlements, so the quote is shaped by how much of that work you need.
- Quoted pricing: Ask for a quote that states the user count basis, the discount tiers and whether the price is per user per month or per year.
- Integration support: Define which WOPI hosts, such as Nextcloud or other platforms, Collabora will help with and where your own team or DeployOpen takes over.
- Customization services: List any branding, configuration or feature work in writing, since it is priced separately from the subscription.
- Roadmap input: Confirm how roadmap requests are submitted and whether they carry any commitment, rather than assuming influence over release timing.
- Ownership of the quote: Ask who on the Collabora side is accountable for the quote and for the support escalation path after cutover.
Confirm the current Enterprise terms and whether your user count qualifies before you plan the cutover date.
The tier you choose changes who you can call during cutover and what evidence you hold when a problem reaches production. The free CODE build is described by Collabora as not recommended for production, so the move from CODE is a change in support model as well as in packaging. Plan the subscription purchase and the repository or image change together, so there is no window where production runs without a supported contract.
- Entitlement start date: Confirm when the subscription becomes effective relative to your planned image or package switch.
- Access to packages: Confirm which repository, registry or credentials your servers will use after the switch, and who holds them.
- Escalation path: Write down who opens a ticket for WOPI host issues, server failures and security advisories, and what information each request needs.
- Documentation of support: Keep the subscription terms, quote and named contacts with your change record for audit purposes.
- Rollback contacts: Include the support contacts in your rollback plan so a failed cutover can be reversed quickly.
Check these points against the written quote and the pricing page before you schedule the cutover.
A short written question list keeps the decision grounded in current terms rather than in assumptions carried over from older releases. Send the questions before you sign, and file the answers with your procurement record. Ask for answers in writing for each point.
- Current terms: Which plan terms, prices and entitlements apply on the date you sign, and when they are reviewed.
- Branch coverage: Which major branches receive long term support and signed security updates, and for how long.
- Support hours and response targets: What the service level agreement covers, measured from which point, and how severity is assigned.
- Named contacts: Who from your organization can open tickets and whether there is a limit on the number of named contacts.
- Renewal and user changes: How user count changes are handled mid-term, and how renewals are priced.
Bring the written answers to your procurement and security reviewers before choosing a tier.
What changes when you move off CODE
This table compares how image sources, support, security patches, release branches and configuration differ between the free CODE build and a supported Collabora Online subscription. Read each row as a question to answer before cutover, and confirm subscriber repository and registry paths with Collabora before you change any pull or install source.
| Change | Impact | Action needed |
|---|---|---|
| Image or package source | The free CODE Docker image is collabora/code, a rolling monthly release that is not recommended for production. Subscribers receive builds through Collabora's customer channels, which differ from the CODE image. | Ask Collabora for the exact subscriber image, registry or package repository paths. Update pull, mirror and deployment manifests only after you have them, and pin the version you test. |
| Support boundary | CODE runs without a contracted service level. A subscription adds long term support, a service level agreement and customer portal access on the Business plan, according to Collabora's pricing page. | Confirm in writing which versions, issue types and response targets your plan covers, and who opens tickets for your environment. |
| Security patch delivery | CODE moves with rolling releases. Subscriptions carry signed security updates. The 25.04 release notes record 25.04.7.5, released January 29, 2026, fixing CVE-2026-23623, and updated package signing keys for RPM and DEB users. | Import the updated signing keys on each package host, and set a patch process that tracks point releases and advisories for your branch. |
| Branch in use | The 25.04 branch was first released on June 19, 2025 and received point releases through 25.04.13 on September 21, 2026. Collabora announced 26.04 on July 23, 2026, with an optional AI assistant that is off by default. | Decide whether you stay on 25.04 or move to 26.04 before cutover. Review the sibling upgrade guidance so the cutover does not change branch and vendor at the same time. |
| Configuration carried over | Settings such as WOPI host allow lists, TLS, proxy routing and resource limits live in your files, not in the image. A new build can read them differently, and the WOPI host must still reach the same server URL. | Export current configuration from the CODE deployment, diff it against the subscription release notes, and test document opens with your WOPI host, including the protocol and URL pairing. |
| Ownership of fixes and evidence | Under CODE, your team holds the full support load. Under a subscription, vendor fixes and advisories become part of your change records and audit evidence. | Record the version, advisory identifiers and patch dates for each host so assessors can trace what ran and when. |
What to complete before the cutover window
Four to six items need to be finished before the switch from CODE to a supported build is scheduled. Each one gives you a rollback point, a known starting state or a test you can repeat after the change. Work through them in the order listed so that the test environment reflects the production configuration you back up.
Back up server configuration and custom settings
Copy the full configuration of the running server, including the WOPI host allow list, proof key settings, TLS certificate and key paths, and any custom logging or resource settings. Store the copy outside the server so you can restore it if the new build rejects a setting. Record the exact image tag or package version currently running, so a rollback targets a known build. Confirm that the allow list still matches the IP addresses or hostnames your WOPI host uses before you change anything.
Inventory the installation and proxy
Record whether Collabora Online runs from Docker, system packages or Kubernetes, and list every component in front of it, such as Nginx, HAProxy or another reverse proxy. Note the ports, the public hostname and the protocol the WOPI host uses to reach it. Capture the proxy rules that route WOPI requests, because a change to the image or package can alter the endpoints the proxy expects. Ask your vendor or the release notes which proxy settings the new branch requires.
Build a matching test environment
Stand up a test copy of your WOPI host at the same version you run in production, with the same Collabora server URL and the same protocol, preferably HTTPS. A test that uses a different URL or an HTTP address can pass while production fails on a mixed-protocol mismatch. Point the test host at the new build and confirm that the connection, the allow list and the document session all succeed before you plan the window.
Assemble a representative document set
Collect test files in docx, xlsx, pptx, PDF and OpenDocument formats taken from real business use, including documents with tracked changes, embedded images, charts, custom fonts and password protection where applicable. Open, edit, save and export each file on the current build and record the result. Repeat the same steps after the change and compare. Differences in layout, formulas or saved output are the most likely reason users report problems after cutover.
List the Nextcloud Office groups
If Nextcloud is your WOPI host, export the groups allowed to use the editor and the groups allowed to edit rather than only view. Confirm which groups hold each permission and who approves changes to them. Keep this list with the change record, because a migration that reinstalls or reconfigures the connector can reset access. After cutover, check that a sample user from each group can open and edit a document as expected.
Confirm subscription holder and portal access
Identify the person or team who will sign the subscription, receive invoices and manage the customer portal. Confirm that named administrators can log in to the portal and that the subscription covers the number of users in scope. Ask the vendor which package covers signed security updates and long term support, and who receives advisories. Without portal access in place before the window, you may not be able to download signed packages or receive a security fix on the day it is needed.
How to switch a production server without losing open documents
This sequence moves a production Collabora Online server from the free CODE build to a supported subscription build in a controlled order, with a check and a rollback point at each stage. The result is a switched server that has been tested against your WOPI host, with the CODE build kept available until you sign off.
Confirm subscription entitlements and portal access
Before touching any server, confirm with Collabora which plan covers your user count and that the people who will install packages or pull images can sign in to the customer portal. Ask the vendor which repository, package source or image name your subscription uses, and which signing keys apply to your package format. The step is done when someone on your team can download the subscription build from the portal or the vendor-provided repository, and you have written down the plan, the account holder and the exact artifact name. Rollback point: nothing has changed yet, so you can stop here at no cost to the running service.
Back up configuration and record the running version
Copy the current configuration files, any proxy or WOPI-related settings, and the service user and file permissions from the production host, and store the copy outside the server. Record the exact installed version, the image tag or package version, and the list of WOPI hosts currently allowed. The step is done when the backup can be restored onto a clean host and the version record matches what the server reports. Rollback point: this backup is the baseline for every later step, so keep it until the switch is signed off.
Install the subscription build in test and carry over configuration
Install the subscription build on a test server that mirrors production, including the same reverse proxy, TLS setup and WOPI host version. Apply the carried-over configuration, then compare the effective settings with the production baseline and resolve any differences you did not intend. The step is done when the test server starts cleanly, reports the subscription build version, and the configuration differences list is empty or each item is explained in writing. Rollback point: the test server can be rebuilt from the backup at any time without affecting users.
Run WOPI host tests on the test server
Run a scripted test set through your WOPI host against the test server covering opening, editing, saving, copy and paste, and the document formats your users depend on, such as docx, xlsx, pptx, PDF and any legacy formats in use. Include a document that several users edit at once and a document opened from a restricted group. Record each result and compare it with the same tests on the CODE build. The step is done when every test passes or each failure has a documented fix and retest. Rollback point: if a format or feature regresses, stay on CODE in production and resolve the issue on the test server first.
Schedule the production window and notify users
Choose a window with low editing activity and tell users in advance that open documents will be interrupted during the restart and that unsaved changes may be lost, so they should save and close files beforehand. Agree the window with the people who own the WOPI host, and name who runs the switch, who checks results and who can call a rollback. The step is done when the notice has been sent, the contacts are written down, and the window is confirmed in your change record. A planned window reduces the risk of interrupting active work because you control when the restart happens and who is affected.
Switch the production image or package and restart
Stop new sessions if your setup allows it, then replace the production image or package with the subscription build using the same configuration you tested. Restart the service and confirm the process starts under the expected service user with the expected configuration. Keep the CODE image or package and the backup in place so you can return to them. The step is done when the service is running the subscription build version and the restart log shows no configuration or permission errors. Rollback point: reinstall the recorded CODE version and restore the backed-up configuration if the restart fails.
Verify health, WOPI connectivity and a test document
Check the health endpoint and service logs, confirm the WOPI host can reach the server through the proxy using the URL it is configured with, and open a test document from the WOPI host. Edit and save it, then check that the change appears on reload and that copy and paste work within the document. The step is done when the health check passes, the WOPI host opens and saves the test document, and the logs show no new errors over an agreed observation period. Rollback point: if any check fails, roll back to the recorded CODE version during the window.
Keep the CODE build available until sign-off
Keep the recorded CODE image or package, the configuration backup and the test results until the business owner, the WOPI host owner and the operations team have signed off the production switch. Confirm the subscription build receives the security updates and support your plan describes, and add the vendor's advisory channel to your patch process. The step is done when sign-off is recorded in writing and the rollback artifacts are archived with the change record. Only then should the CODE artifacts be removed according to your retention policy.
What makes the switch take longer than a package swap
This table lists the factors that expand a CODE to subscription move beyond swapping packages or images. Read each row against your own estate: the more a driver applies, the more testing, coordination and rollback planning the switch needs. Most of the effort sits in multi-server routing, Kubernetes control, and the number of integrations and users affected by the window.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Number of Collabora servers and load balancing | Every server must run the same release and configuration during the change. If the load balancer does not route by WOPISrc, users editing one document can land on different servers and lose their session. | Confirm the balancer routes by WOPISrc before the window. Drain or move open documents server by server, and keep the old and new pools separate until each has passed tests. |
| Kubernetes or Helm deployment with the COOL Controller | Replicas are set manually in the official chart, and pod restarts close open documents. Controller and chart versions must match the target release, so the change touches more objects. | Pin chart and app versions in version control, plan a rolling restart that moves open documents, and review monitoring rules before the switch. |
| Custom configuration and proof key settings | Settings carried over from CODE may not match the subscription deployment. Proof key and WOPI host settings tie editing to the host, so a mismatch can break every editing session at once. | Export the current configuration, diff it against the target, and test proof key validation with the actual WOPI host before cutover. |
| Number and variety of document formats in use | Each format family (OpenDocument, Microsoft formats, PDF, RTF, CSV, Visio) carries its own fidelity risk. Heavy use of macros, templates or complex layouts widens the test set. | Build a sample set from real files by format and department, then compare rendering before and after the switch. |
| Number of WOPI hosts and integrations | Each host, such as Nextcloud or another platform, has its own allow list and URL settings. Each one must be retested after the switch, and some hosts may run separate Collabora URLs. | List every WOPI host and its Collabora URL, confirm the allow list for each, and assign a named tester per integration. |
| Number of users who must be told about the window | Users with open documents lose unsaved changes if editing stops mid-session. The more users and departments, the more notice, scheduling and support coverage the switch needs. | Agree a window with business owners, send advance notice, ask users to close documents, and staff a support contact during the change. |
| Availability of test environments | Without a staging copy of the production configuration and WOPI hosts, problems surface in production. Teams that lack staging usually spend more time on rollback planning. | Ask whether a staging environment mirrors production routing, hosts and documents. If not, budget for building one as part of the scope. |
What buyers ask before moving off CODE
What does a supported Collabora Online subscription cost?
Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, and the Enterprise plan for 100 or more users is quoted with volume discounts. The Business plan includes long term support, a service level agreement, signed security updates and customer portal access. Confirm current figures on the Collabora pricing page before budgeting, because the subscription is billed by Collabora, not DeployOpen. Ask Collabora whether the plan covers every server in your setup, including test and staging systems, and how the user count is measured. DeployOpen's implementation work is quoted separately from the written scope and is not part of the subscription price.
How does the subscription cost change with user count?
The Business plan price scales with the number of users, so cost rises in step with headcount until the Enterprise threshold of 100 users, where pricing becomes a quote. Support needs also shift the figure. Integration support, customization services and roadmap input appear in the Enterprise plan, so an organization with custom WOPI hosts or frequent change requests should ask whether those needs push it there. Ask for the per user rate at your exact count, the renewal terms, and which support hours and response commitments each plan includes. Compare that against how many hours your own team would spend on patching and upgrades each year.
How long does the move from CODE to a subscription take?
The duration depends on how many servers run CODE, how the WOPI host is connected, and how much custom configuration must carry over. Most of the time goes to inventory, testing documents across formats, and agreeing a change window with users. Adding a new package source or container image is usually quick by comparison. Ask for the timeline in the written scope rather than relying on a general estimate, and check that it includes a rollback step. Collabora's release notes for each branch should be reviewed during planning, since they can change behavior that testing needs to cover.
What must our team provide before the switch starts?
Preparation goes faster when your team supplies a few specific items:
- An inventory of every Collabora Online server, container or pod, with its version, install method and the WOPI hosts that call it.
- A set of representative test documents in the formats your users edit, such as docx, xlsx, pptx and PDF.
- Administrator access to the WOPI host, for example the Nextcloud Office settings, so integration tests can run.
- A change window agreed with document owners, plus a named contact who can approve the cutover.
Also confirm who holds the Collabora customer portal account, because the subscription and security updates depend on it.
Can our own team move from CODE to a supported subscription?
Yes, a capable platform team can make the switch in-house if it has time, a test environment and a clear picture of the current setup. The work is mostly changing the package or image source, carrying configuration across, restarting services and running integration tests against the WOPI host. A partner helps most when the deployment is large, uses Kubernetes or routing that must respect WOPISrc, has heavy customization, or when the team lacks capacity for testing and rollback planning. Consider the risk of a failed cutover during business hours. DeployOpen plans, implements and tests this work in your infrastructure under a written scope.
Can we roll back to CODE after switching to a subscription?
A rollback is possible in principle because the server code is the same MPL-2.0 licensed product, but it should be planned rather than assumed. Keep a copy of the working configuration, the previous package or image tag, and a backup of any data the server touches before the change. Test the reversal in a staging environment so you know how long it takes and whether open documents are affected. Note that moving back to CODE means losing the support entitlements that the subscription provides for the period it was active. Confirm the procedure with Collabora and your WOPI host vendor before the change window.
Does the subscription change how we receive security fixes?
Collabora publishes security advisories for Collabora Online, and subscribers receive signed security updates as part of the Business plan. Packages and keys can also change over time. For example, Collabora's 25.04 release notes record that package signing keys were updated for RPM and DEB users. Ask Collabora how you will receive advisories, which repository or registry serves the subscription build, and how key rotation is communicated. Assign an owner to watch for these notices and schedule patch windows, because security updates are only useful if they are applied on time.
When to schedule the switch around branch releases
Schedule the move to a supported subscription around two separate release tracks: point releases within a branch and the major branch itself. Point releases arrive on their own cadence. The 25.04 branch, for example, was first released on June 19, 2025 as 25.04.2.3 and was still receiving point releases, with 25.04.13 released on September 21, 2026, according to the Collabora Online 25.04 release notes. A point release is usually a fix change within the branch you already run, so it should not force a configuration review. A major branch such as 26.04 is a different kind of change. It brings new features, including an optional AI assistant across Writer, Calc and Impress that is off by default, and administrators choose the AI provider and whether it is hosted externally or on their own infrastructure, according to the Collabora Online forum release post for 26.04.
Where possible, keep the subscription move separate from any branch upgrade. If you combine them, you change the image or package source, the support entitlement and the branch in one window, and a fault becomes hard to attribute. Before combining, confirm with Collabora which build and branch the subscription delivers for your platform, whether that is a Docker image, system packages or a Kubernetes chart, and whether the same branch is available through the customer portal. Record the exact version you run today so you can roll back to it if the new source behaves differently. Check the newest branch's notes for signing key or repository changes before you add it to the same change set.
Confirm all release, point release and support end dates directly with Collabora before you set a window, since these dates change and this page does not treat any date as fixed. Ask for the support period that applies to the branch you will run on the subscription, and whether a branch you plan to skip still receives signed security updates for your plan. Plan the window around your WOPI host's own release schedule too, so that a Nextcloud or other host change does not land on the same day as a Collabora branch change.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the move from CODE to a supported subscription runs in your cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory which CODE images, packages or Helm values are in use and which WOPI hosts depend on them.
- The written scope names the target subscription tier, the repository or image changes, and the servers in each environment.
- Quotes follow from the written scope, and we confirm with you which support entitlements the scope depends on.
How we build
- We stage the switch in a non-production environment that mirrors your WOPI host and proxy configuration.
- We carry configuration across, review it against current release notes, and test document fidelity with your real file types.
- We rehearse the cutover and rollback steps for each server before any production change is made.
How we hand over
- You receive a runbook covering repository sources, image tags, configuration differences and the rollback procedure.
- Test results from the WOPI host integration and document round trips are documented against the agreed scope.
- Your team walks through the cutover record, and we confirm who holds subscription credentials and portal access.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover monitoring of new point releases and advisories, with patching planned in your change windows.
- Support terms, response expectations and included hours are set in the written agreement, so confirm them before signing.
