Testing document fidelity before a Collabora Online rollout

Why testing document fidelity before a Collabora Online rollout protects users

Before you give users browser-based editing of documents they already have, you need evidence of what changes when those files are opened and saved in Collabora Online. Document fidelity testing is the check that shows whether layout, tracked changes, comments, fields, styles, formulas and macros survive the trip intact. Without it, the first sign of a problem is usually a user reporting a broken contract, a shifted table or a lost comment after go-live, when the damage is already in the files. Fidelity means more than whether a file opens. It covers how pages break, whether revisions and review comments remain attached to the right text, whether fields such as page numbers and cross-references update, whether named styles are kept or flattened, and whether spreadsheet formulas and charts calculate the same way.

A generic sample test is not enough because the risk sits in your own documents. Collabora Online supports OpenDocument formats, docx, xlsx and pptx, plus PDF, RTF, CSV and Visio files, according to the Collabora Online product page. That list tells you what the software can open, not how your templates, legal clauses, financial models or clinical forms will behave. Your test plan should follow the formats your organization actually uses and the documents that would hurt most if they changed. Ask the people who own those documents to nominate the files they cannot afford to get wrong, and record which features each file depends on.

Teams need this work at three points: before go-live, before a version upgrade of Collabora Online, and before changing the default save format. Each event can change rendering or round-trip behavior, so a result from one point does not prove the next. Confirm with Collabora which release notes and known issues apply to the version you plan to run, and keep the same corpus so results are comparable over time.

How to build a representative document corpus

This sequence produces a classified, sanitized set of test documents that reflects what your organization actually edits, so fidelity testing measures real risk rather than sample files chosen for convenience.

Inventory document sources across the organization
Ask file share owners, Nextcloud or other storage administrators, mailbox and records teams, and business unit leads where Word, Excel, PowerPoint, PDF and legacy files live today. Include shared drives, document management exports, templates folders, and email attachment stores. Record each source with its owner, approximate file count and access rules. The step is done when every storage location that will move to Collabora Online has a named owner and an inventory entry.
Collect a sample from each source
Pull a sample from every inventory entry rather than only the most recent or most visible files, since older documents often carry the layouts and features that break first. Preserve original timestamps and paths in a manifest so you can trace any test file back to its source. Copy files read-only into a staging area, and keep the original repository untouched. The output is a collection manifest with one row per file and its source location.
Classify files by format, feature and criticality
Tag each file with its format (DOCX, XLSX, PPTX, ODF, PDF, RTF, CSV, Visio or legacy), the features it uses such as tracked changes, comments, fields, macros, pivot tables, embedded media or form controls, and its business criticality as agreed with the document owner. Criticality should reflect what happens if a file renders or saves incorrectly, such as contracts, regulatory submissions or financial models. The output is a classification sheet that lets you select representative subsets for each risk area.
Remove sensitive content from copies
Sanitize the staging copies before any file reaches a test environment. Remove or replace personal data, credentials, client names, account numbers and embedded metadata such as author fields, revision history and hidden comments, and confirm that the sanitization did not remove the features you are trying to test. Keep a log of what was changed in each file so reviewers know which differences are intentional. Run the sanitized set through your data handling policy review, and record who approved access to the test corpus. The step is done when the approver signs off on the sanitized set and the access list.
Record the source application version for each file
For every Word, Excel and PowerPoint file, record the version of the application and operating system that created or last saved it, where that can be determined from the file metadata, the document owner or the storage system. Note whether the file was last saved by Word for Microsoft 365, an older desktop release or a mobile or web client, since these differences can change how features are written. Record unknown values as unknown rather than guessing. The output is a version column in the classification sheet that you can use when comparing results later.
Add templates, external files and archives deliberately
Check that the corpus contains the categories most likely to surprise you: corporate templates with styles, content controls and locked sections; files received from outside the organization, including those from partners, regulators, customers and public bodies; and archive collections that may hold older formats or bulk conversions. Compare each category against your inventory. For any category with no entries, either collect samples or record a documented gap with the reason. The corpus is complete for this step when each template family, external source and archive group has at least one entry or an approved gap.
Confirm coverage and freeze the corpus
Review the classification sheet against the inventory and the risk areas defined for the rollout. Confirm that every format in scope, every criticality tier and every source owner appears in the corpus, and that high-criticality files have been reviewed by the people who use them. Assign a stable identifier to each file, store a checksum alongside it, and freeze the corpus so later test runs compare like with like. The output is a versioned corpus with a coverage report that the rollout owner signs off before testing begins.

Round-trip testing in Collabora Online and Microsoft Office

The first approach checks whether Collabora Online can open each file in your corpus and display it without losing layout, content or structure. The test runs no edits. An operator opens the file in Collabora Online, captures the rendered output, and compares it with a reference rendering taken from the Microsoft Office version your organization uses. This is the cheapest test to run and the first gate, but it only shows what the viewer shows. Nothing in it proves that a later save preserves the file.

Import errors: Record files that fail to load, load with a warning, or load with missing content such as images, embedded objects or hidden sheets.
Visual comparison: Compare page breaks, line endings, table widths, fonts and slide layouts against the Office reference at the same zoom level.
Structural check: Confirm that headings, styles, numbering, sheet names and slide order appear as they do in the source file.
Font substitution: Note every font the viewer replaces, because substitution changes pagination and can look like a layout defect.
Limits: A clean render does not prove that formulas, fields, comments or tracked changes survive an edit and save cycle.

Before accepting any render result, check that the reference rendering was produced from the same file version, with the same fonts installed, and that the Office build used for the reference is recorded in the test log.

Which test method fits which rollout situation

This table compares four ways to test document fidelity before a Collabora Online rollout: manual sampling, scripted comparison with mso-test, a pilot on a staging instance, and an outsourced fidelity test. Read each row against your own document mix, team size and go-live date to see which method, or combination, fits your situation.

Method	Best fit when	Internal effort and what it misses	What to confirm before choosing
Manual sampling by business owners	Few templates, a small set of critical documents, and owners who can judge layout and comments by eye	Owners spend time opening and comparing files in Word and the browser. Misses subtle style, field and macro changes and is hard to repeat after each update.	Which owners will sign off, how many documents each will review, and where findings will be logged
Scripted comparison with mso-test	Large corpora, frequent Collabora Online updates, and a need for repeatable before and after results	Engineers build and maintain the corpus and scripts and triage the differences. Scripts flag measurable changes but cannot judge whether a change matters to a business reader.	Whether the tool and its current version run in your environment, and how its output maps to your blocker criteria
Pilot group on a staging Collabora Online instance	Real users need to work with live documents in the same integration, such as Nextcloud, before go-live	Staging must match production versions, fonts and WOPI settings. Pilot users need guidance and a way to report issues. Misses problems that appear only at production concurrency.	Staging version and host settings, the pilot group and its duration, and how feedback reaches the test team
Outsourced fidelity test	Internal staff lack time or Office-side expertise, or an independent record of results is required for governance	Internal staff supply documents, access, and decisions on blockers. The provider runs the corpus and reports findings. Misses business context the provider does not have unless you supply it.	Scope in writing, the document types and volume covered, the report format, and what happens to retested fixes

What to log for each fidelity issue and how to rate it

Every fidelity finding should be recorded the same way so that a reviewer can reproduce it, judge its impact and assign it to someone who can fix or accept it. The cards below cover the fields a defect record needs and the severity categories that decide whether a finding blocks go-live.

Source file and format

Record the exact file name, a checksum, the file format and the extension, and whether the file came from a template, a converted archive or a user's own export. Note the original authoring application and its version, since a file saved by an older Word build can behave differently from one saved today. Keep an untouched copy of the source so the issue can be reproduced after the file has been edited or re-saved during testing. Without the original bytes, a finding cannot be confirmed by anyone else.

Collabora Online version and deployment

Record the exact Collabora Online version, the branch (for example, 25.04 or 26.04), the install method (Docker image, system package or Kubernetes), and whether the server runs as CODE or a supported subscription build. Include the host application, its version and the browser used for the session. A fidelity issue seen on one branch may be fixed on the next, so the version is what lets the team retest against a known build. Collabora Online release notes help confirm which fixes a version includes.

Office reference version and render

Record the Microsoft Office build, platform (Windows, macOS or web) and the rendering result the reader compared against. Save a PDF or screenshot from Office next to the Collabora Online render so the difference can be checked later without the original application. Note any font substitution on either side, because missing fonts often create layout drift that looks like a format defect. Without a fixed reference, two testers may disagree about what the correct output is.

Feature, steps and expected result

Name the feature affected, such as tracked changes, a named style, a chart, a formula or a field. Write numbered reproduction steps that start from opening the source file and end with the observed result, and state the expected result from the Office reference. A reviewer should be able to repeat the steps in a clean session and get the same outcome. Mark any step that depends on a specific user, group or sharing setting, because permissions can change what the editor shows.

Cosmetic drift versus loss of content

Cosmetic drift is a change in spacing, line breaks, colors, icon shapes or pagination that leaves the content and its meaning intact. Loss of content is a change that removes or alters data a reader depends on: text, cell values, formulas, tracked changes, comments, hidden rows or digital signatures. Rate any finding that changes a number, a formula result, a signature status or a tracked change as loss of content until a reviewer proves otherwise. Treat drift that moves a legal clause onto a different page as higher risk than drift that only shifts a logo.

Severity, impact and owner

Assign one of a small set of severity levels that the rollout group agreed before testing started, such as blocker, high, medium and low, and define each level in terms of business effect. Record who is affected, how many users or templates it touches, and whether a workaround exists. Name a single owner for each defect, whether that is the platform team, the document owner or the vendor, and set a review date. Blockers are the findings that decide go-live, so their owner and status should be visible to the sign-off group.

Deciding which fidelity gaps block go-live

Set the go-live criteria with business owners before the first test runs, because a fidelity gap only becomes a blocker once someone has agreed what it would cost them. Sort every observed difference into two groups. Blocking defects include data loss, broken formulas, tracked changes or comments that disappear in legal or contract workflows, and PDFs that cannot be opened or exported in a readable state. Acceptable differences are cosmetic shifts such as slight spacing, font substitution or minor chart styling changes that users can work around. Acceptable differences still need written user guidance, such as which template features to avoid or where to check the output before sending it externally.

Record the decision as a release record that names each blocking criterion, the formats and templates it covers, and the owners who sign it: typically the business process owner, the records or legal lead, and the platform owner. Scope matters as much as the verdict. A criterion for Word contracts does not cover the spreadsheets your finance team builds, and a sign-off for one template family does not extend to others. Keep the record with the test corpus and the Collabora Online version it was tested against so that the evidence can be reproduced later.

A pass on a sample does not certify every file in your estate. The corpus represents the documents you chose, and real archives will contain features, macros, embedded objects and fonts that the sample lacks. State this limit in the release record. Treat any change of Collabora Online branch as a trigger for retesting the blocking criteria, for example when moving from the 25.04 branch to 26.04, since rendering and filter behavior can change between branches. Confirm the current point release and its change notes with Collabora before you set the test baseline, and rerun the blocking tests after every upgrade.

Handling sensitive documents during fidelity testing

Fidelity testing means opening real business documents, so the test environment needs the same care as production. The cards below cover where the test runs, who can reach it, how copies of documents are handled, and what is kept after testing ends.

Use a staging deployment you control

Run the fidelity tests on a staging Collabora Online deployment inside infrastructure your organization controls, separate from production. Keep the staging server, its Nextcloud or other WOPI host, and its storage on the same network and cloud accounts your security team already audits. Confirm with your provider where any test traffic is routed, and do not point test documents at a hosted service you have not assessed under your data rules.

Restrict WOPI requests to Collabora

The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, and using HTTPS for the Collabora server URL with the same protocol as the Nextcloud installation. Apply both on the staging stack, then confirm that a request from any other address is refused. Mismatched protocols are a common cause of failed sessions, so check them during the first test run.

Limit which groups can edit

In Nextcloud Office, administrators can limit which groups can use the editor and which groups can edit rather than only view. For fidelity testing, create a small named group for testers and give it edit rights only on the test corpus folders. Testers working on sensitive samples should not share accounts, and every edit session should be traceable to one named person.

Handle production copies under existing rules

Copies of production documents used as test samples are still personal or confidential data, so they fall under the same classification, retention, and access rules as the originals. Ask your data protection owner to approve each source set and its purpose in writing before copying. Where possible, use redacted or synthetic documents that keep the layout, styles, and objects that matter for fidelity but remove the sensitive text.

Purge test artifacts

Round-trip testing creates converted copies, exported PDFs, screenshots, and comparison files, and each one holds document content. Define a retention period for these artifacts before testing starts, and delete them from storage, backups, and any shared issue tracker at the end of the test window. Record the deletion in the test report so auditors can see that the controls ran as planned.

Keep document content out of logs

Server and client logs can capture file names, paths, and sometimes excerpts from documents, which turns a test log into a copy of the data. Set log levels for the staging stack to what you need for troubleshooting, review what the issue log records, and describe defects by document ID, page, and object type rather than by quoted text. Check the logs once after the first session to confirm that nothing sensitive was written.

Questions teams ask before running fidelity tests

How much effort does a Collabora Online fidelity test need?

Effort scales with how many documents you test, how many formats are in scope and how many people must review the results. A test of a few dozen representative files across one format is a very different job from a corpus covering Word templates, Excel models, PowerPoint decks and PDFs for several departments. The main drivers are corpus size, the number of distinct templates and document types, the number of formats in scope, and the time reviewers can spend comparing each file against its original in Microsoft Office. Ask any partner to break the estimate down by format and by reviewer hours, and to state which files will be compared side by side and which will only be opened.

Can our internal staff run fidelity testing themselves?

Yes, many teams run the core of it internally, provided they have someone who understands both the documents and the business rules behind them. Staff who know which templates are legally or operationally critical are often the best reviewers, and they do not need to learn Collabora Online internals to judge whether a letterhead, table or formula still behaves correctly. Where internal teams usually need help is in building a representative corpus, setting up a repeatable comparison method, and agreeing on severity levels for issues. Confirm your team has access to Microsoft Office for reference rendering and to a test instance of your planned Collabora Online version.

How long does a fidelity test take, and what sets the duration?

Duration is set by corpus size, the number of review cycles and how quickly defects are fixed or accepted. The first pass usually takes longer because the corpus, the test environment and the issue log all have to be built, and later passes go faster if the same files are rerun. Other factors include whether any issues need changes to templates, fonts or Collabora Online configuration, and whether business owners sign off in one round or several. Ask for a schedule that lists each stage, its owner and its exit criteria rather than a single overall duration, and confirm which dates depend on your own reviewers and change windows.

What does the work need from business owners?

Business owners need to identify the documents that matter, approve the severity rules and accept or reject residual differences. Without their input, a test can report hundreds of cosmetic differences that nobody is able to rank. Owners should provide representative templates, examples of documents that have caused problems before, and named reviewers with time booked during the test window. They also decide what counts as a go-live blocker, for example a broken approval workflow or a lost tracked change in a contract, and what is acceptable as a known limitation with a workaround. Confirm these decisions in writing before the first review.

Is mso-test enough to validate fidelity on its own?

No. mso-test is useful for automated checks of how documents round-trip, and it can catch regressions that are easy to miss by eye. It does not replace human review of layout, comments, tracked changes, fields, embedded objects or business-specific formulas, and it cannot judge whether a document still means what its author intended. Treat automated results as a filter that shows where to look, then use a sample of human-reviewed documents to confirm the outcome. Check the tool's documentation for the formats and versions it covers, and confirm with your Collabora Online version which checks apply.

How should we retest after a Collabora Online upgrade?

Rerun the same corpus against the new version, compare results with the previous baseline, and review only the differences that changed. Keep the baseline outputs, the issue log and the severity decisions from the earlier test so the comparison is fair. Upgrades between major branches, such as moving between the 25.04 and 26.04 lines described in Collabora's release notes, deserve a full review, while point releases can often be checked with automated comparison plus a smaller human sample. Include security-relevant updates in the same cycle, because patch levels also change behavior. Confirm your upgrade path with the vendor's release notes before scheduling the retest.

What does a Collabora Online subscription add to the test budget?

The Collabora pricing page lists a Business plan at 3 euros per user per month for up to 99 users, which includes long term support, a service level agreement, signed security updates and customer portal access. Plans for 100 or more users are quoted with volume discounts and add integration support, customization services and roadmap input. Fidelity testing itself is a one-time effort, while a subscription recurs, so keep the two separate in your budget. Ask any partner to quote testing, remediation and retesting as distinct line items, and confirm whether the free CODE edition is in scope for your test environment, since Collabora describes it as not recommended for production.

What to ask for in a fidelity testing quote

A fidelity testing quote should list each written scope item separately, because each one drives effort in a different way. Ask for the corpus definition and sign-off first: the number of files, the formats and the template families they cover, and who on your side approves the set before testing starts. Effort rises with corpus size and with how many custom templates, macros and legacy files are included, so the quote should state the counts it assumes. You provide the sample files, ideally pulled from real shares with their document owners' consent, plus named reviewers who can judge whether a rendering difference matters to the business.

The test matrix sets how many combinations are run: each format (DOCX, XLSX, PPTX, ODF, PDF and any legacy formats in scope) crossed with the Collabora Online version you intend to deploy and the Office versions your users run. Ask the provider to name the Collabora Online release and branch being tested, and to say whether they will rerun the matrix when a point release lands. Reference testing in Microsoft Office needs licensed installs of the same Office versions, so confirm whether you supply those licenses or the provider brings them. The quote should also name the tooling, including whether a comparison tool such as mso-test is used and how its output is interpreted, since automated comparison still needs human review. Ask for the defect log format to be agreed in writing, with fields for file, format, element, expected behavior, observed behavior, severity and owner.

Finally, ask for the retest rounds (how many are included and what triggers an extra round), a written go-live criteria document that defines which defect classes block rollout, and a handover package covering the corpus, scripts, logs and the criteria used to decide. Retest rounds and blocker definitions are the two items most likely to change the final cost, so agree them before signing. Confirm whether the criteria will be reviewed by your compliance or records team, since DeployOpen prepares evidence but does not issue assessment outcomes. Current Collabora Online release details are published on the Collabora Online product page, which the provider should reference when describing the version under test.

How DeployOpen scopes and delivers fidelity testing

DeployOpen treats fidelity testing as a fixed-scope piece of work: the corpus, test matrix, issue format and go-live criteria are agreed in writing before testing starts. The cards below follow that sequence, from scoping to the retesting that follows each upgrade, and they show where your team keeps control and where DeployOpen prepares the evidence.

Written scope before testing

Before work starts, DeployOpen agrees in writing which document families, templates, languages and workflows the corpus covers, which Microsoft Office versions are the reference, and which Collabora Online version is under test. The scope also names what is out of bounds, such as macros or niche formats you do not use. Ask for the scope document to list every test case and its owner, so a later dispute about coverage can be settled from the document rather than from memory.

Corpus built from your documents

The corpus is drawn from your own templates, contracts, financial models, decks and archives, with sensitive content handled under your data rules. Representative means covering the features your users depend on, such as tracked changes, fields, styles and embedded objects, not just the easiest files. Confirm who selects the samples, how personal data is removed or replaced, and where the corpus is stored.

Tests run in your environment

Round-trip and rendering tests run on a Collabora Online instance inside your cloud accounts, data centers or air-gapped network, so documents never leave the environment they are meant for. Microsoft Office reference renderings are produced on machines you provide or approve. Confirm which hosts, accounts and network paths testers need, and who holds the credentials after the engagement closes.

Issues logged in an agreed format

Each finding is recorded with the source file, format, feature, Collabora Online version, the expected result from Microsoft Office and the observed result, plus a severity your team agrees in advance. Consistent records make it possible to see whether a problem is a single template issue or a pattern across many files. Ask for the issue template and the triage rules before the first run, and for evidence such as screenshots or exported files to be attached.

Go-live evidence and decisions

DeployOpen prepares the fidelity evidence, including test results, open issues, workarounds and a summary against the criteria you set, so your team can decide whether to go live. DeployOpen does not issue audit reports, attestations or certifications. If an independent assessment is part of your program, the assessor decides what the evidence supports, so agree early on the format that assessor expects.

Retesting after upgrades

Collabora Online ships new branches and point releases, and each one can change rendering. DeployOpen offers retainers that rerun the agreed corpus after upgrades and after template changes, and compare results with the earlier baseline. Ask whether the retainer includes the same corpus, the same issue format and the same reference versions, so that differences show up as true regressions rather than new test conditions.