Microsoft Office file compatibility in self-hosted document editing starts with your own templates
If you exchange .docx, .xlsx and .pptx files with customers, the question is whether a self-hosted browser editor will keep layout, tracked changes, fonts and spreadsheet formulas intact when your team edits them. Both ONLYOFFICE Docs and Collabora Online can open and save these formats, but they reach that result differently, and the only reliable way to choose is to test your own documents. In short, ONLYOFFICE Docs is built around Office Open XML as its native format, while Collabora Online is built on the LibreOffice engine and supports docx, xlsx and pptx. Neither product is a drop-in replacement for desktop Office in every case, so the decision should rest on evidence from your files rather than on vendor summaries.
Start by assembling a test set drawn from real working files: customer-facing proposals with tracked changes and comments, spreadsheets with named ranges, array formulas and conditional formatting, decks that use embedded or licensed fonts, and any templates with content controls or form fields. Open each file in both editors, make the edits your teams actually make, save, and reopen in desktop Office. Compare page breaks, table widths, numbering, chart rendering, and whether formulas recalculate to the same values. Record the failures by file and by feature, since a fidelity problem in one template is often a font or a single object type rather than the whole format. Confirm font handling with your own administrators, because missing fonts on the server change pagination more than most settings do.
DeployOpen plans and runs this kind of comparison as part of implementation, and it prepares the test set, configuration and evidence for your review. It does not certify fidelity, and no test by a partner replaces your own acceptance criteria. Keep desktop Office for the edge cases your test set shows to be unstable, such as complex macros or heavily formatted legal documents, and define in writing which file types are routed to the desktop application. Ask the vendor or partner to confirm which editions carry the support and security updates you need before you sign off on the results.
How ONLYOFFICE and Collabora Online differ on Office formats
ONLYOFFICE Docs treats .docx, .xlsx and .pptx as its native formats. Its DocumentServer README lists these Office Open XML files as native, with conversion paths for formats such as DOC, ODT, RTF, ODS, CSV and ODP. For teams whose main exchange format is Microsoft Office, this means the editing engine is built around the same file structure your customers send, which makes it a natural first candidate for fidelity testing. The Community Edition is licensed under AGPL-3.0, and the same codebase is sold as commercial editions with additional features.
- Native Office Open XML handling: Documents, spreadsheets and presentations open in the formats your partners already use, so there is no conversion step for the primary file types.
- PDF editing and forms: The suite includes text editing, page manipulation, annotations and form filling for PDF files, which matters for contracts and forms that move between teams.
- Docker as the recommended install path: The project recommends Docker, which makes it simpler to pin versions and rebuild the document server in a repeatable way.
- Enterprise Edition features: The edition comparison lists an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support as Enterprise features. Community support runs through GitHub and the forum, and configuration is done through config files.
- Commercial embedding terms: A separate Developer Edition under a commercial license applies to software vendors that embed the editors in services they provide.
Confirm with ONLYOFFICE which edition your user count and support needs require, and check the current edition comparison before you commit to a configuration.
Collabora Online is built on LibreOffice technology, so its editing engine is a different codebase from ONLYOFFICE even though both open Office files. According to the Collabora product page, it supports OpenDocument formats and Microsoft formats including docx, xlsx and pptx, plus PDF, RTF, CSV and Visio files. Because the engine is LibreOffice-derived, the places where it differs from Office are often the same places where LibreOffice differs from Office, so your test plan should focus on those areas.
- LibreOffice rendering engine: Documents are rendered by a LibreOffice-based engine, which can produce different pagination, table layout or chart appearance than desktop Office for complex templates.
- MPL-2.0 source license: The server code is licensed under the Mozilla Public License 2.0, which has file-level copyleft obligations that differ from AGPL-3.0. Have counsel review the terms for your use.
- CODE is not for production: The free CODE edition is described by Collabora as suited to testing, home use or small teams and not recommended for production.
- Paid plans add support and signed fixes: The paid Collabora Online adds tested updates, security fixes and support. The pricing page lists a Business plan at 3 euros per user per month for up to 99 users, with long term support, a service level agreement, signed security updates and customer portal access, and an Enterprise plan quoted for 100 or more users.
- Wide WOPI integration: Collabora lists WOPI integrations with platforms including Nextcloud, ownCloud, Seafile and Mattermost.
Before you choose, run your own templates through a Collabora Online test instance and confirm the pricing and plan terms with the vendor.
Neither editor is a drop-in replacement for desktop Office across every document. Differences tend to appear in a small set of areas that matter most in customer-facing documents: page layout, tables, charts, macros, and fonts. These are areas where any non-Microsoft engine must reconstruct how Office would have drawn the page, so small variances can change how a contract or financial model looks to the recipient, even when the text is correct.
- Layout and pagination: Headers, footers, section breaks, floating objects and line breaks can move, which changes page counts and cross-references.
- Tables and charts: Merged cells, nested tables, conditional formatting and chart styles are common sources of visual drift in both editors.
- Macros and scripts: VBA macros in .docm or .xlsm files are not a general compatibility target, so confirm whether any of your files depend on them.
- Fonts: Missing or substituted fonts change line breaks and table widths. Confirm which fonts your templates use and whether your server image includes them.
- Round-trip edits: Open, edit and save the same file several times and compare the result with the original in desktop Office.
Build a test set from your most important templates and have the people who receive them review the output, because a file that looks correct to the editor's author may still differ for the customer.
Public feature lists do not show how a specific template will render, so the decision should rest on a fidelity test with your own documents. The test should cover the file types you exchange most, the features your templates depend on, and the people who check the result. A fair test uses the same files in both editors, the same fonts on both servers and the same reviewers, with results recorded against a written acceptance list.
- Select a representative set: Include short letters, long contracts, financial models, slide decks and any form templates, drawn from real exchanges with customers.
- Standardize the environment: Use the same fonts, browser versions and document server versions for each editor, and record the exact versions tested.
- Define acceptance criteria: Specify what counts as a defect, such as a shifted table, a changed page break or a broken chart, and who signs off.
- Test edit, save and re-open cycles: Verify that a file saved in the editor opens correctly in desktop Office and that tracked changes and comments survive.
- Check concurrency and collaboration: Confirm that co-editing, comments and version history behave as expected for the users who will work in the editor.
Record the results per file and per feature, then ask the vendor or implementation partner to explain each defect and whether it can be fixed by configuration, template change or fonts.
How to test Office fidelity on your own templates before choosing
This sequence turns your real customer documents into evidence, so the choice between ONLYOFFICE and Collabora rests on how your files render and round-trip, not on feature lists. Each phase produces a named artifact that the next phase depends on.
Collect representative templates from customer exchanges
Gather the .docx, .xlsx and .pptx files your teams actually send to and receive from customers, including contracts, quotes, financial models and decks with embedded charts. Pull them from the systems where they live, such as shared drives, the CRM and email archives, and keep the originals unaltered. Ask legal, finance and sales leads to nominate the files that matter most. The step is done when you hold a test corpus with a manifest listing each file, its owner, its source and the customer-facing purpose it serves.
Classify each file by fidelity risk
Sort the corpus by how much layout, formula or chart behavior a difference would damage. Typical high-risk items include files with tracked changes, complex numbering, form fields, linked or embedded Excel charts, macros that are removed on save, and slides with custom fonts or SmartArt. Low-risk items are plain text letters and simple tables. Record the risk class and the reason beside each file. The output is a classified corpus that tells you which files must pass and which may only warn.
Open and save each file through the same integration
Run every file through one test environment for each candidate editor, using the same WOPI or API connection your users would use, the same fonts and the same browser. Open, edit lightly, save, reopen and export back to the original Office format. Confirm the test environment matches the production font set, because missing fonts distort pagination. The output is a run log per file and editor showing what opened, what saved and any errors returned.
Compare rendering and round-trip results against desktop Office
Compare each editor's output against the same file opened and saved in the desktop Office version your customers use. Check pagination, table breaks, headers and footers, numbering, cross-references, spreadsheet formulas and calculated values, chart appearance and slide transitions. Use side-by-side PDF exports and a structured checklist so reviewers judge the same points. The output is a comparison sheet per file that marks each difference as identical, cosmetic or functional.
Log each defect with its severity
Enter every difference into a defect register with the file name, editor, version, steps to reproduce, a screenshot or export, and a severity such as blocking, major or cosmetic. Assign a business owner to each entry and mark whether a workaround exists. Ask the editor vendor or community to confirm reproducible defects before you score them. The output is a defect register that gives the decision group an objective list rather than anecdotes.
Agree a pass threshold with business owners
Before you read the results, meet with the owners of each document class and agree what counts as a pass. Define which defect severities block adoption, how many cosmetic differences are acceptable, and which files must round-trip with no functional change. Document the threshold so it is not moved after the results arrive. The output is a signed threshold note that names the owner for each document class.
Record the go or no-go decision and its edge cases
Score each candidate editor against the threshold and write a go or no-go record for each document class. Where a file class fails, record whether it stays on desktop Office, moves to a different workflow, or is accepted with a documented limitation. Include the editor edition, version and integration tested so the decision can be repeated at upgrade time. Confirm the record with the business owners and security lead. The output is a dated decision record that also feeds your requirements and support contract.
Format requirements that change the build and where they come from
This table lists the format and records obligations that shape a self-hosted editing build, where each one originates, and what it means for design. Read it before running any fidelity tests, because each row tells you what to verify on your own templates. The main takeaway is that fidelity, PDF output, fonts and retention are usually set by your customers and regulators rather than by the editor you pick.
| Requirement | Source of the requirement | What it means for the build |
|---|---|---|
| Round-trip fidelity of .docx, .xlsx and .pptx | Customer contracts, partner templates and your own document standards | Test open, edit and save cycles on real templates in both editors; log layout, tables, fields and macros that break before choosing |
| Version and comment retention | Internal document policy and customer review expectations | Confirm the editor writes tracked changes and comments back intact and that your file platform keeps prior versions on save |
| Customer-facing PDF output | Customer delivery terms and how recipients open documents | Verify PDF export keeps fonts, page breaks and form fields; agree a sign-off sample set with the business owner |
| Font availability for rendering | Licensed corporate fonts used in customer documents | Install licensed fonts in the document server image; missing fonts substitute and shift pagination, so track font packages as build inputs |
| Records retention for documents sent and received | SEC Rule 17a-4(b)(4) for broker-dealers: communications kept at least three years, including inter-office communications | Only where you are a broker-dealer: retain originals of received and copies of sent files in a non-editable form with defined retention periods |
| Audit controls on documents containing ePHI | HIPAA Security Rule audit controls, 45 CFR 164.312(b) | Only where you handle ePHI: log who opened, edited and exported each document, and confirm the editor forwards that activity to your audit store |
Which editor fits which Office file profile
Most organizations do not need one editor for every file. The right choice depends on which Office features your templates use, whether PDFs and forms are part of the exchange, and which platform will host the editor. The cards below set out the decisions that connect those factors.
ONLYOFFICE Docs for Office-heavy work
ONLYOFFICE Docs treats .docx, .xlsx and .pptx as its native formats, which makes it a common first test for Office-heavy document and spreadsheet work. It also edits PDFs, including text, annotations and form filling, so teams that send fillable forms to customers can keep that step in the same editor. Check tracked changes, comments, complex tables and spreadsheet formulas against your own files before you commit. Its product licensing is AGPL-3.0.
Collabora Online for LibreOffice fidelity
Collabora Online is built on LibreOffice technology and opens docx, xlsx and pptx alongside OpenDocument, PDF, RTF, CSV and Visio files. Choose it when your inputs include Visio diagrams or RTF exports, or when your team already works in LibreOffice. Test how it renders your specific templates, since Word-specific layout and spreadsheet behavior can differ from the Office original. Its server code is licensed under MPL-2.0.
Paid edition versus CODE for production
CODE is the free development edition, which Collabora describes as suited to testing, home use or small teams and not recommended for production. The paid Collabora Online adds tested updates, security fixes and support, which matters once editors depend on the service for daily work. Ask the vendor which build your fidelity tests used, because a test on CODE does not prove the behavior of a supported release. Confirm plan limits with Collabora's current pricing page.
Nextcloud or Seafile as the WOPI host
Where your file platform is Nextcloud or Seafile, the editor is attached to that platform through the WOPI protocol, so users open Office files in the browser from where they already store them. Confirm which connector your chosen editor supports for your file platform version, and confirm that the editor can reach the host and the host can reach the editor. Both Nextcloud Server (AGPL-3.0) and Seafile server (GPLv2 with an OpenSSL linking exception) have their own licensing to review alongside the editor.
Desktop Office for macro-heavy files
Some workbooks depend on VBA macros, add-ins, data connections or intricate print layouts that browser editors do not reproduce. Identify these files in your inventory before rollout and keep desktop Office for them, or redesign them with the business owner. Browser editing can still handle the bulk of routine documents. Ask each editor vendor which macro and add-in features are unsupported, and document the exceptions as part of your fidelity sign-off.
When to keep desktop Office for edge cases
Keep desktop Office licenses for the small set of files that fail your test corpus in ways customers will not accept, and decide that per file family before rollout rather than during an incident. The usual candidates are workbooks with complex VBA macros, COM add-ins or Office-specific automation, pivot-heavy financial models that depend on exact pivot cache behavior, and documents with tightly controlled print layouts such as forms printed on preprinted stock. Browser editors can open and edit many of these files, but opening is not the same as producing an identical result, so the decision rests on your own defect log, not on a feature checklist.
Route these files with a written rule that the editing platform can enforce. Options include a file-type or folder-based exclusion in the file platform, a metadata tag applied at upload or by a classification step, or a shared rule that users open these items with the desktop client and never save them through the browser editor. Ask your implementation partner to confirm which of these your file platform and document server can honor, and test the handoff: a file opened in the browser, flagged, and then returned to desktop Office should keep its version history and sharing permissions intact. Assign an owner for the exclusion list and review it whenever the test corpus changes.
Record each exception in a register that names the file family, the defect or dependency that justifies it, the authoritative copy (desktop Office or the browser editor), the approver and the review date. Show the register to users in the same place they meet the files, such as a banner in the file platform or a line in the document template, so nobody guesses which tool is authoritative. Retain the register with your configuration records, because auditors and customers may ask how you chose between tools. Confirm with your Microsoft licensing contact what desktop entitlements your current agreement covers, since keeping a subset of desktop seats is a procurement decision separate from the editor choice.
Integration points that affect how Office files render
Office file fidelity in a self-hosted editor depends less on the editor alone than on how it is wired into your file platform, container image and access model. The six points below are the settings that most often change how a .docx, .xlsx or .pptx file looks and behaves once it leaves your environment.
WOPI host configuration
The file platform hands each document to the editor through WOPI, and the host settings decide which files open, which operations are allowed and how the editor reads and writes the file back. A misconfigured host can open a file in a view-only or converted state without an obvious error. Confirm the WOPI endpoint, the allowed hosts and the file types registered for each editor against a test file set before go-live.
Fonts installed in the editor container
Layout in Word, Excel and PowerPoint depends on font metrics. If a font named in a file is missing from the editor container, the editor substitutes another face, and line breaks, table widths and slide text can shift. Ask your partner which Microsoft core fonts and customer-specific fonts are packaged in the image, how they are licensed, and how you add a font without rebuilding the whole stack.
File conversion and storage on the platform
Some editors convert files on open or on save, and storage layers may re-encode or rename them. Each conversion step is a place where content, styles or embedded objects can change. Document which formats are opened natively, which are converted, and whether the platform keeps the original upload alongside the edited copy, so you can compare outputs against the file a customer sent.
Versioning and retention settings
Version history determines which copy a customer receives after a round of co-editing, and retention rules determine how long originals and intermediate versions remain. Where records of business communications must be kept, the retention period should be set from your own regulatory obligations, not from editor defaults. Confirm what the platform stores on each save, how long versions persist, and who can restore an earlier copy.
Access rights for edit versus view
Whether a user can edit, comment, or only view a file is set in the file platform and passed to the editor on each session. A recipient who should only read a contract must not be able to alter tracked changes or formulas, and a reviewer may need comment rights without edit rights. Test each role with a sample document and confirm that the editor enforces the same restrictions as the file share.
PDF export for customers
Many organizations send customers a PDF rather than the source Office file. The export path decides whether fonts are embedded, whether tables and slide notes survive, and whether form fields or tracked changes appear in the output. Compare exported PDFs with the source file on your own templates, and confirm which editor version and font set produced each export so the result can be reproduced later.
Evidence that proves format handling to auditors and customers
This table lists the evidence items you should be able to produce about how Office files are handled, which component generates each one, and what it shows. Treat every row as an input for an independent assessor or a customer's security review, not as a certification. The main takeaway is that fidelity claims are only credible when they are backed by your own templates, versioned records and access logs.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Fidelity test corpus | Your representative .docx, .xlsx and .pptx files (templates, tracked changes, macros removed, embedded fonts, charts) with the expected rendering and round-trip result for each | Your test plan and corpus, run against ONLYOFFICE Docs or Collabora Online |
| Fidelity test results | Per-file pass, fail or accepted-difference outcomes for open, edit, save and re-export, with screenshots or diff output and the reviewer's name | Test harness or manual test log, with the editor version under test recorded |
| Defect register | Each formatting, font, layout or formula defect found, its severity, workaround, fix version and whether a customer-facing file was affected | Your issue tracker, linked to the editor's upstream bug reports where relevant |
| Version and edition record | Exact editor build, document server image digest, font package versions and edition (Community, Enterprise or paid Collabora tier) in each environment | Deployment manifests, container image inventory and vendor release notes |
| Update and signature record | Which security or format fixes were applied, when, and whether packages were verified before install | Change tickets, package verification logs and the vendor's release channel |
| Retention log for exchanged files | Which Office files were received and sent, where they are stored, and how long originals and versions are kept under your policy | File platform (for example Nextcloud or Seafile) retention settings and storage backup records |
| Audit log of access (HIPAA 164.312(b) or similar) | Who opened, edited or downloaded a document, from which WOPI host and when, for systems holding ePHI or regulated records | File platform audit log, WOPI host logs and document server access logs forwarded to your SIEM |
| Transmission protection record | Evidence that editing traffic between browser, WOPI host and document server uses encrypted channels (HIPAA 164.312(e)(1) context) | TLS configuration on the reverse proxy and document server, with certificate inventory |
Questions buyers ask about Office compatibility before hiring help
What drives the effort of Office fidelity testing?
The effort depends mostly on how many templates and document types your business exchanges, how complex their layouts are, and how many of them carry features that the editor must render exactly. Tables with merged cells, tracked changes, embedded charts, custom fonts, macros, form controls, slide masters and mail merge fields each add review time. Start with an inventory of the files you send to customers and receive from them, group them by template family, and mark the ones where a shift in pagination or numbering would cause a real business problem. A short list of high-risk templates usually determines the work more than the total file count. Ask any partner to show how they will score differences, because a visual diff tool and a manual review by the file owner produce very different effort.
Can our own team run the Office compatibility test without a partner?
Yes, a capable internal team can run the test, provided it has the time, a test environment that matches production, and people who know the documents well enough to judge the output. The work includes building a corpus of sample files, opening and saving each file in the candidate editor and in desktop Office, comparing pagination, styles, tables, charts and fonts, and logging every defect with a severity. Most teams underestimate the sign-off step. Someone in the business must decide whether a difference is acceptable for each template family. A partner adds value when the corpus is large, when you need repeatable test automation, or when fixes require configuration changes to the document server or font packages. Confirm who will own the results before you start.
How long does a fidelity test cycle take?
The duration depends on corpus size, the number of defects found and how many retests each fix needs, so no fixed timeline applies across organizations. A cycle usually has four phases: corpus preparation, first-pass rendering comparison, defect triage with the file owners, and retest after fixes. Defect count drives the most variation, because each fix to fonts, styles or conversion settings can change output for other templates and force another pass. Ask for a written plan that states the number of files in each test round, the acceptance criteria, the number of retest rounds included in the scope, and the dates on which business owners must return their decisions. Treat any timeline offered without those inputs as an estimate to challenge.
What does the business need to provide for the test?
The test needs representative sample files, named owners who can judge the output, and a written sign-off process. Sample files should come from real customer exchanges, including older versions, files created on different Office releases, and files that other organizations sent to you. Owners are the people who created or depend on each template, such as contracts, proposals, financial models or board decks. Sign-off means each owner accepts or rejects the rendering of their templates against stated criteria, and that the decision is recorded. Without these inputs, the test can produce many defects that nobody is authorized to close, which slows the whole cycle. Also confirm which fonts your customers use, because missing fonts are a common source of pagination differences.
Is a community build enough, or do we need a supported edition?
A community build can be enough for a pilot, a small team, or a test environment, but production use across customer-facing documents usually calls for a supported edition with security fixes and an agreed support path. Collabora describes its free CODE edition as suited to testing, home use or small teams and not recommended for production. Its paid Collabora Online adds tested updates, security fixes and support, and its Business plan costs 3 euros per user per month for up to 99 users, according to the Collabora Online pricing page. ONLYOFFICE lists admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support as Enterprise Edition features. Compare the license terms, support levels and the features your deployment needs with the current pricing pages before choosing.
Can we remove desktop Office completely after moving to browser editing?
Most organizations keep desktop Office for some edge cases, so complete removal should be a deliberate decision, not a default. Browser editors handle common business documents well, but complex macros, specialized add-ins, some advanced chart types, certain legacy binary formats and specific print layouts may behave differently. Build a list of the edge cases your test uncovers and assign each one an owner and a decision: fix the template, change the workflow, or keep a licensed desktop installation for that group. The edge case list also tells you which roles can work fully in the browser. Plan the desktop exception policy before rollout so users are not surprised when a document opens differently for them.
Questions to put to an implementation partner on Office format fidelity
Start by asking how the partner will build the test corpus from your files. A useful answer names the sample: which customer-facing .docx, .xlsx and .pptx templates, which contract and report forms, and which files carry tracked changes, comments, content controls, embedded charts, custom XML or legacy .doc origins. Ask who selects the files, whether the partner will take a representative sample from your document stores under a data handling agreement, and how sensitive content is kept inside your environment during testing. Ask for the corpus inventory in writing before any editor is installed, so both ONLYOFFICE Docs and Collabora Online are scored against the same files and the same checklist.
Font handling is the most common cause of visible layout drift, so ask which fonts are installed on the document servers, where they come from and under what license each one is used. Ask whether the partner maps the fonts your templates depend on, including any corporate or licensed typefaces, and how substitutes are chosen when a font is missing. For spreadsheets, ask how formulas, named ranges, data validation and pivot tables are tested after a round trip, and whether macros are excluded, converted, or blocked. Ask what happens to .xlsm files and VBA projects, who decides whether a macro is supported in the browser editor, and where that decision is recorded. A clear written position on macros is a sound signal of a careful partner.
Ask how round-trip edits are tested in both editors: open, edit in the browser, save, reopen in desktop Office and compare, then repeat in the other direction. Ask how defects are logged, what severity scale is used, and who decides pass or fail. You should be the final approver for any defect that touches a document your customers rely on. Finally, ask how editor updates are tested before rollout: whether the partner keeps a regression set that is rerun on every new release of the editor, how signed updates are verified, how a rollback is performed, and whether the test evidence is kept for your audit file. Confirm each of these answers against the current release notes of the editor you choose before you sign.
Rollout phases for Office compatibility in production
This sequence moves Office file compatibility from an assumption to a documented decision, so each editor is tested against your own files before customers depend on it. Each phase closes with a named output that the next phase needs.
Inventory files and exchange paths
The document owner or records lead, with a representative from customer-facing teams, lists the file types exchanged with customers, the Office versions used on both sides, and the channels involved, such as email attachments, portal uploads and shared drives. The step closes with a file inventory that records format, version, owner, volume and whether the file is edited, only viewed or only signed. You know it is done when every exchange path has a named owner and a listed file type.
Build the test corpus and rank risk
The team selects a corpus from the inventory that includes real templates, documents with tracked changes, comments, embedded charts, complex tables, custom fonts, macros that must be removed, and content that uses Office features the business relies on. Each file is ranked by business impact and by how often it is edited in the browser. The output is a versioned corpus with a risk class for each file. Confirm with the business owners which classes must reach full fidelity before pilot.
Run parallel fidelity tests in both editors
The test team opens every corpus file in ONLYOFFICE Docs and Collabora Online, edits it, saves it, and reopens it in desktop Office and the other editor. They record layout shifts, lost formatting, broken formulas, altered charts, font substitution and round-trip differences in a shared defect log. The output is a per-file comparison with a pass, pass with known deviation, or fail result. Repeat the run after any editor update, and confirm the fonts installed on the server match the fonts your customers use.
Pilot with a customer-facing group
A small group of account managers or contract staff uses the chosen editor for the files in the moderate and high risk classes, while desktop Office stays available for every other workflow. Pilot users log each deviation with the file, the action and the recipient's reaction when the file came back. The output is a pilot log and a decision on which file classes may move to the browser editor. Confirm the pilot stays inside the access rules set for the document platform before any external recipient receives output.
Cut over to production with desktop fallback
The platform owner enables the approved editor for the approved file classes, publishes written guidance that tells staff which files go to desktop Office, and keeps a documented fallback path for any file that fails in production. The output is a signed cutover record, the fallback procedure, and a named contact for compatibility issues. You know the cutover is complete when staff can open the approved files in the browser and the fallback has been tested on at least one file from each class.
Review compatibility after each editor update
After every update to the editor, the test team reruns the corpus, compares the results with the previous baseline and updates the defect log and risk classes. The platform owner decides whether the update is approved, held or rolled back. The output is a dated review record that links each change to the editor version it was tested against. Confirm the update source and signing process with your editor vendor or implementation partner before applying the update to production.
How DeployOpen scopes and tests Office compatibility
DeployOpen treats Office compatibility as a measurable question answered with your own files, not a feature claim. We scope the file types, templates and editing workflows that matter to your customers, then build and test a self-hosted editor against them before any production rollout.
How we scope
- Inventory the .docx, .xlsx and .pptx templates your customers send and receive, grouped by business workflow
- Agree which editor, ONLYOFFICE Docs or Collabora Online, is in scope for the fidelity test and why
- Define pass criteria for layout, tables, tracked changes, fonts, macros and charts in writing
- Document which formats stay out of scope and which desktop Office edge cases remain with users
How we build
- Deploy the chosen editor inside your own cloud account, data center or air-gapped network
- Run a fidelity test matrix on your templates, comparing rendered output against the original desktop Office files
- Log every deviation with a file, a version and a reproducible step so the owners can decide on each one
- Set fonts and conversion settings so test results reflect the environment users will actually work in
How we hand over
- Deliver a written fidelity report listing passed, partially passed and failed cases for each template
- Provide configuration documentation, the test corpus and the steps needed to repeat the tests after updates
- Record the desktop Office fallback rules and who approves exceptions for customer-facing files
- Train named administrators on upgrade, rollback and re-running the test matrix on new releases
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Re-run the fidelity matrix when the editor is upgraded, using the same corpus and pass criteria
- Ongoing support, upgrades and continuous testing are available as a retainer
- Ask any partner for the written scope, the test corpus format and the upgrade process before signing
