What a Collabora Online migration involves
A Collabora Online migration replaces the editor that opens and saves documents from inside your file platform, so the first decision is which editor you are leaving and what it currently handles. The usual starting points are Microsoft Office for the web, Office Online Server, or another WOPI-compatible editor. Common triggers include license or hosting changes, data residency requirements that rule out an external editing service, and a decision to retire an editor that no longer fits your environment. Write down the trigger, because it sets the deadline and the acceptable risk for the cutover.
Collabora Online is built on LibreOffice technology and runs as a server that the host reaches through the WOPI protocol. The host, most often Nextcloud, hands the editor a file reference and an access token, and Collabora returns the editing interface in the browser. The migration therefore touches two sides: the WOPI host configuration that points at the new server, and the documents themselves. Confirm with your host's documentation which WOPI endpoints and allow list settings must change, and which editor configuration will be removed or left in place during the transition.
Teams that already run WOPI integrations and understand Office formats can usually plan and execute the migration in-house. Teams without that experience often bring in a partner for two areas where mistakes are costly: checking how existing docx, xlsx and pptx files render and save in Collabora before users depend on them, and sequencing the cutover so that open documents and templates do not break. Either way, the work is driven by the document inventory and the host configuration, not by the server install alone.
What the work includes
A Collabora Online migration moves document editing from an existing editor into a WOPI host that you operate. The work below covers the checks and changes that decide whether users can edit their files on the day of cutover.
Inventory of documents and editors
We catalogue the file types, volumes, owners and current editors in use, including which documents are edited through Microsoft Office for the web or Office Online Server and which are shared through the WOPI host. The inventory sets the scope for every later check and shows which formats and integrations need testing first.
Format compatibility testing
We open and save a representative set of docx, xlsx and pptx files, plus PDF, RTF, CSV and Visio files where your teams use them, and record where layout, formulas, macros, comments or tracked changes differ. Results are documented per format so your team can decide which differences are acceptable and which need a workaround.
Template and style migration
We review corporate templates, named styles, headers, footers and document properties, then rebuild or port them so that new documents created in Collabora Online match existing branding. Each template is tested for pagination and style inheritance, since small differences here are the most visible to end users.
Font inventory and licensing
We list every font referenced by existing documents and templates, identify which are embedded, which are installed on user machines only, and which carry licenses that restrict server-side use. Confirm the license terms of each proprietary font with its vendor before the server package is built.
WOPI host configuration and allow lists
We configure the WOPI host to point at the Collabora server, set the server URL to the same protocol as the host, and restrict WOPI requests to the addresses of your Collabora servers. Group rules determine which users can edit and which can only view, and these settings are tested for each group before cutover.
Staged pilot and cutover
We run a pilot with a defined user group and file set, then move remaining users in stages so each wave can be checked and paused. Each stage has entry and exit criteria, and open-document sessions are handled so that users do not lose unsaved work during the switch.
User communication and training
We prepare notices, quick reference guides and short hands-on sessions covering what changes for users, including differences in shortcuts, comments and sharing. Training material is written for your help desk as well, so first-line support can answer the questions that come in during the pilot.
Rollback planning
We define the conditions that trigger a rollback, the steps to restore the previous editor for each host and group, and how documents edited during the pilot are reconciled. The rollback plan is rehearsed before cutover, so the team knows the sequence under pressure.
Deliverables handed to you
You receive an inventory report, compatibility test results, a template and font package, the configured environment, a cutover runbook and handover notes for your operations team. Together these let your own staff run, verify and roll back the platform after the engagement ends.
What drives effort and how to keep it down
This table lists the factors that change migration effort for Collabora Online, why each one matters and how to contain it before cutover.
| Driver | Why it matters | How to contain it |
|---|---|---|
| Document volume and age | Every file needs a format and fidelity check, and older files often carry legacy structure that renders differently. | Inventory files by type and age, migrate active documents first and archive the rest in place. |
| Templates and macros | Macros written for Microsoft Office may not behave the same in the browser editor, and templates control formatting across many documents. | List every macro and template, rebuild the ones in active use and retire the rest before the pilot. |
| Font variety and licensing | Missing or substituted fonts shift pagination. Some font licenses limit server-side installation. | Inventory fonts used in documents, confirm licensing terms with each font vendor and install approved fonts on every server. |
| Formats beyond docx, xlsx and pptx | Legacy Office formats, PDF, RTF, CSV and Visio files each need their own test cases and conversion checks. | Confirm which formats your WOPI host allows and test each one with representative sample files. |
| Concurrent editors and peak load | Each collaborative session uses server memory and CPU, and peak concurrency sets capacity more than averages do. | Measure peak editors, then size pods against the Helm chart README production limits of 8 CPU cores and 8000 MiB memory. |
| WOPI hosts and integrations | Each host adds its own allow list, identity, access rule and file handling work, so scope grows with every host. | Start with one host, document WOPI settings per host and restrict requests to known Collabora server addresses. |
| Environments (test, pre-production, production) | Each environment needs its own servers, certificates, host settings and test documents. | Keep configuration in version control, use synthetic or approved sample documents in test and promote the same build through each stage. |
| Source editor features with no direct equivalent | Some features in the current editor may not map one to one, which creates retraining needs and workflow gaps. | Inventory the features users rely on, test each one in the browser editor and agree workarounds before cutover. |
| Edition choice (CODE or subscription) | CODE is free but not recommended for production. Subscriptions set the support, update and integration scope. | Ask Collabora in writing what each edition covers and match it to your production support needs. |
Project phases and outputs
The sequence moves from an inventory of real documents to a staged cutover, so each phase confirms format fidelity and user readiness before the next one starts.
Inventory documents, hosts and users
DeployOpen and your team catalog the current editors, WOPI hosts, file types, template libraries, fonts and user groups in use. The output is an inventory listing every document type that will move, the editor it uses today, and the owners who approve changes. The phase closes when the owners have signed off the inventory as complete.
Test formats and templates on a sample
DeployOpen opens and saves a representative sample of docx, xlsx and pptx files, including templates, macros where relevant, tracked changes, comments and embedded objects, in Collabora Online. Differences in layout, pagination, formulas and charts are recorded against each sample. The output is a test report that lists each file, the observed differences and a decision for each one: accept, fix or keep in the old editor.
Remediate fonts and templates
Missing fonts, substituted fonts and templates that render poorly are fixed by installing approved fonts on the Collabora servers, correcting template files or adjusting document styles with the document owners. The output is a font set and template set that match the sample report, with each change logged so a reviewer can trace why it was made.
Pilot with a small group in non-production
A pilot group of real users opens and edits their own documents in a non-production environment that mirrors the planned WOPI host configuration. Feedback is collected on rendering, saving, co-editing and access rules. The output is a pilot sign-off that lists open issues, their owners and the fixes that must land before production. Timing depends on the inventory and your change windows.
Cut over in stages by group or document type
Production access is enabled in stages, starting with the groups or document types agreed in the pilot. Each stage has a rollback path to the previous editor and a check of save and co-editing behavior before the next stage opens. The output is a cutover log recording each stage, the groups affected and the checks passed. Timing depends on your change windows.
Review after cutover
After the final stage, DeployOpen and your team review support tickets, open defects, format complaints and usage against the inventory. Remaining items are assigned and documented in the runbook. The output is a post-cutover review record with a list of closed and open issues, and the operating handover to your support team.
What stays in-house and what a partner takes on
This table compares each migration work area with who usually performs it, the skills it needs and what to confirm before agreeing on an owner, so you can see where your team and a partner would each carry effort.
| Work area | Usually performed by | Skills required |
|---|---|---|
| Document inventory | Your team, with partner review of file types and volumes | Knowledge of which departments own which templates and macros, plus records and retention policy |
| Format testing for docx, xlsx and pptx | Shared: partner builds the test set, your users check their own files | Office document expertise covering layout, tracked changes, macros and complex spreadsheets |
| Template rework | Your document owners, with partner support on technical fixes | Office document expertise and an understanding of which templates the business still relies on |
| Font licensing review | Your legal or procurement team, with partner checks on font availability | Licensing knowledge for each font family and how embedded fonts render on the server |
| WOPI host configuration | Partner, with your host administrator | WOPI protocol knowledge and experience with the chosen host, such as Nextcloud Office settings |
| Reverse proxy and TLS routing | Partner or your platform team, depending on existing standards | Reverse proxy configuration, certificate handling and WOPISrc-aware routing |
| Load testing with realistic editing sessions | Partner designs and runs the tests, your team reviews results | Load testing tools, Linux administration and the ability to read server metrics |
| Cutover and rollback | Shared: your change board approves, partner executes runbooks | Change management, Linux administration and clear rollback criteria agreed in advance |
| User training and communication | Your team owns delivery, partner supplies materials | Change management, internal communications and a view of how staff edit documents daily |
| Post-cutover support and fixes | Your service desk for triage, partner for defects if under retainer | Support process design, log analysis and familiarity with the release branch in use |
What usually goes wrong
These are the failures that most often surface when document editing moves to Collabora Online. Decide the pilot and production editions early, because Collabora does not recommend CODE for production.
Layout and pagination shifts
Page breaks, table widths, section headers and slide text fitting can move when a docx or pptx file is rendered by a different engine. Compare a representative set of long reports, legal templates and slides with embedded charts in the editor your users will use. Record which shifts are acceptable and which need a fix in the source file before cutover.
Formula, pivot and chart differences
Functions with version-specific behavior, pivot tables, structured references and linked charts can calculate or display differently in xlsx files. Test the workbooks that finance and operations teams depend on, comparing key totals cell by cell against the original output. Confirm which functions and pivot features are supported before the pilot, and plan a fallback for any that are not.
Missing fonts and template drift
A document that relies on a corporate font reflows when that font is missing and a substitute is applied. Templates also change over time, so files created from older versions may not match the current master. Install approved fonts on every Collabora server, confirm the font licenses permit that use, and keep template versions under change control.
Macros and add-ins that do not carry over
VBA macros, Office add-ins and task panes built for Microsoft Office for the web or Office Online Server are not expected to run in Collabora Online. Inventory every macro and add-in in use, and identify the business process each one supports. Decide whether each is rebuilt as a host-side service, replaced by a native feature or retired, and communicate that decision before the pilot begins.
Read-only opens and failed saves
Files open read-only when edit rights, group settings or lock state deny write access, and saves can fail when the WOPI host rejects an update. Test edit and view groups with real accounts, and check how the host handles large files and slow saves. Pilot with files from every group and folder that will move, not only a sample created for testing.
Dual editing and missing rollback
While two editors remain available, the same file can be changed in both, and the later save can overwrite the earlier one. Set a switch date for each user group, block the old editor for migrated file types, and rehearse reverting the host's editor configuration in staging. A cutover without a tested rollback leaves no safe way back if the pilot surfaces a blocking problem.
How the work changes by starting point
Both Microsoft sources put docx, xlsx and pptx files at the center of the work, but the starting systems differ. Office for the web is hosted by Microsoft, so your team tests against the behavior users see today. Office Online Server runs in your own data center, so its WOPI endpoints, certificates and patch level must be inventoried first.
- Testing: Open a sample set of each format from your document library, including files with tracked changes, comments, embedded charts and complex tables. Record what differs after conversion.
- Cutover: Run both editors side by side for a pilot group, then switch the default per file type once results are accepted.
- Access control: Map existing sharing and view-only rules to the group edit and view rights your WOPI host supports, and confirm the mapping before users move.
- Retirement: Keep Office Online Server endpoints reachable until open sessions close and archived files are confirmed.
When the WOPI host already runs another editor, the host's integration, file storage and sharing model stay in place. The change is mainly the editor service the host calls, so the work concentrates on how documents open, lock and save.
- Testing: Confirm that existing files open in edit mode, that locks are released on close, and that saved files keep their formats and metadata.
- Cutover: Change the editor server URL and the WOPI allow list in the host, and keep the previous editor reachable so the change can be reversed.
- Access control: Check which group settings the host already applies and whether each one has the same meaning in the new editor.
- Templates and fonts: Compare template files and fonts used by the old editor with what the new server renders, and record any differences for the business owners.
A self-managed Collabora Online server on an older branch changes the work from a platform swap into an upgrade with a host-side check. Collabora publishes release branches by year and point releases within them, and security fixes arrive in point releases, so the target version should be chosen from the current release notes.
- Testing: Run a regression set on the target version in staging, including documents saved by the older server and files with complex layouts.
- Cutover: Upgrade in a staging copy of the host integration first, then move production during an agreed window with a documented rollback path.
- Packages: For RPM and DEB installs, confirm that package signing keys are current on every node before the upgrade begins.
- Access control: Review the WOPI allow list and admin console settings after the upgrade, since defaults and configuration keys can change between branches.
On Kubernetes, the migration keeps the same document tests but adds routing and replica behavior to verify. The official Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing, so replica counts are set by hand. The full deployment detail sits in the Helm topic.
- Testing: Have two or more users open the same document and confirm that all sessions reach the same pod through WOPISrc-based routing.
- Cutover: Plan the ingress change, since Nginx, HAProxy and OpenShift Router each need the routing rule configured.
- Access control: Restrict which namespaces and services can reach the Collabora pods, and keep the WOPI allow list limited to the host.
- Reference: See the Collabora Online on Kubernetes with Helm topic for replica counts, resource requests and ingress options.
In an air-gapped or restricted network, the editor cannot fetch fonts, templates, images or updates from outside. Each of those must be staged inside the network before testing starts, and every test must pass without outside access.
- Testing: Run the format and rendering tests offline, and confirm that fonts and templates load from internal storage.
- Cutover: Move container images or packages through your approved transfer process, and rehearse the import at least once in a non-production environment.
- Access control: Limit WOPI requests to the Collabora server addresses, use HTTPS between the host and the editor, and keep the AI assistant off unless its provider runs on your own infrastructure.
- Verification: Check package signatures and record the update source for each release used in the migration.
What the client needs to provide
Most delays in a Collabora Online migration come from inputs that were never assigned, not from the editor itself. Before scoping is signed off, the client should name one accountable owner for each of these areas: the business owner who decides which documents matter, the WOPI host owner (for example, the Nextcloud or other platform administrator), the identity owner who controls sign-in and group membership, and the owners of the test and production hosting. Each owner should be able to make changes and approve test results without waiting for a steering committee.
The technical inputs are concrete. Provide a document sample that spans docx, xlsx and pptx files from different periods and authoring tools, including macros, tracked changes, comments, embedded objects and password-protected files where they exist. Provide access to the existing editor and its configuration, such as Microsoft Office for the web or Office Online Server settings, so the team can record current behavior. Supply font files with license evidence, since missing fonts are a common cause of layout drift. Name the template owners who must sign off on rendering of letterheads and forms.
Hosting access must cover both the test and production environments, including the WOPI host configuration, reverse proxy and DNS changes, and certificate management. Agree a change calendar early so that freeze windows and cutover slots are known. Ask the business to decide which formats and features must work on day one, such as tracked changes, comments, or specific templates, and which can wait. Those decisions define the acceptance tests.
Decide the target edition and the cutover approach early, because both shape the build. Whether the rollout uses CODE or a Business or Enterprise subscription changes support expectations, update cadence and the number of environments you can plan around. The cutover approach, whether a pilot group, a staged user migration or a single switch, determines how long old and new editors must run side by side and what rollback looks like. Confirm current subscription terms and support scope with Collabora before committing to either path.
Frequently asked questions
Can our own team migrate to Collabora Online without outside help?
Yes, if the team has Linux server administration, reverse proxy and TLS skills, administrative access to the WOPI host and identity system, and time to test actual files. Named staff must own scope and cutover decisions, supply sample documents from each department, and provide change windows for the host and proxy. Collabora's free CODE edition is suited to testing, home use or small teams and is not recommended for production, so production use means planning a supported deployment. Outside help usually pays off when the team lacks test capacity or the cutover must be staged across user groups.
What drives the cost and timeline of a migration?
Cost and duration follow the same drivers: the size and variety of your document estate, the number of WOPI host integrations and templates to test, the number of concurrent editors the servers must support, and how many groups move in stages. One-time work covers scoping, sizing, testing and cutover. Recurring items include infrastructure and any subscription; Collabora's pricing page lists the Business plan at 3 euros per user per month for up to 99 users. Ask for a written scope with phases, deliverables and exit criteria, and treat any timeline as provisional until that scope is agreed.
Will our Word and Excel documents look identical after migration?
Not automatically, so test before you commit. Collabora Online supports docx, xlsx and pptx alongside OpenDocument formats, but layout, pagination, charts, fonts and advanced features can differ between editors. Test a representative sample from each department, compare rendering and round-trip saves, and record which documents need manual fixes. Keep these results as acceptance evidence. DeployOpen does not certify document fidelity; the outcome depends on your files and the tests you agree in advance.
How should we handle macros, templates and fonts during a move?
Inventory them first, then decide case by case. Treat every Office macro as needing review, and confirm with Collabora how each macro type behaves in the version you plan to deploy before assuming it will carry over. Test templates for styles, headers, footers and placeholder fields. For fonts, list every font your documents use, confirm you hold the license for each, and install the approved fonts on the servers. Fonts missing from the server are substituted, which changes line breaks and pagination, so font coverage belongs in the acceptance tests.
Can users keep using the old editor during the transition?
Often yes, if the WOPI host lets you control which users or groups see which editor. Nextcloud Office, for example, lets administrators limit which groups can use the editor and which groups can edit, or only view, so a pilot group can move first. Keep the old editor available for groups not yet cut over, set a clear end date for parallel use, and monitor which formats each group opens. Confirm that both editors can open and save the same files during overlap before you promise parallel use to users.
What support does a migration partner provide after cutover?
Support after cutover depends on the written agreement, so confirm it before work starts. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing. Ask whether the retainer covers monitoring, incident response, Collabora point releases and security advisories, and how moves to newer yearly branches are handled. Collabora's Business plan includes long term support, a service level agreement and signed security updates, which you should compare with your own support model.
How DeployOpen delivers this service
DeployOpen plans, builds, documents and supports Collabora Online migrations inside your own infrastructure, moving document editing from your current editor in stages that your users can verify before cutover. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every WOPI host, editor entry point and Office editor in use today, including who edits what and from where.
- Run a sample of real docx, xlsx and pptx files through the target editor to record formatting, macro, and embedded-object differences.
- Agree in writing which templates, fonts, languages and file types are in scope, and which are excluded from the migration.
How we build
- Configure the WOPI host connection, server URL, allow list and group-based edit or view rights in a staging environment first.
- Prepare template and font packages, then test rendering of representative documents against the original Office output.
- Set up a staged cutover plan with pilot groups, rollback steps and a defined period where both editors remain available.
How we hand over
- Deliver runbooks covering configuration, certificate and package update steps, and the migration decisions recorded during the project.
- Document the file format test results, known rendering differences and user guidance agreed with your document owners.
- Walk your operations team through monitoring, log review and the steps for returning a user group to the previous editor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Ask any support proposal to name the Collabora Online release branch it covers and how point releases will be applied in your environment.
- Confirm with Collabora which edition and subscription terms apply to your user count before the retainer scope is written.
