Document editing RFP questions to ask before you choose a platform
If you must put self-hosted browser editing of Office files out to vendors or partners, the document editing RFP questions in this section give you a common set to compare answers fairly. Send the same written questions to every bidder, in the same order, and ask each one to answer in writing with the specific component, setting or document it refers to. Assign answers to the people who own them: the platform or infrastructure lead for hosting and scaling, the security team for WOPI traffic and update signing, the application owner for file format testing, and procurement for editions and support terms. Score the responses against your own requirements rather than against the bidder's marketing.
The questions are neutral between Collabora Online and ONLYOFFICE. Each platform can be a valid answer, and the same questions apply to both, so ask every bidder to justify its choice with evidence from your own test files and user counts. Ask for the license of each component you would run, the edition and support plan the bidder recommends for your user count, and the written scope that covers installation, integration with your file platform, and hardening. Also ask which parts the bidder will not do. DeployOpen plans, implements and supports self-hosted platforms, runs security testing and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask any bidder, including DeployOpen, to name the independent auditor or certification body that will assess your environment.
Which questions to ask about platform, scale, routing, editions, fonts and updates
Should we choose Collabora Online or ONLYOFFICE Docs, and why?
Choose on the editing engine, the licence obligations and the support model you need, then test both on your own files. Collabora Online's server code is licensed under the Mozilla Public License 2.0, which is a file-level copyleft, and it is built on LibreOffice technology. ONLYOFFICE Docs Community Edition is licensed under AGPL-3.0 and is built around the Office Open XML formats (.docx, .xlsx, .pptx) as native formats. A good answer names the exact product and version under evaluation, explains how each licence applies to your planned use (internal use, or embedding in a service you sell), and states which edition carries the support and signed updates you need. Ask the vendor to confirm the licence text in the repository you will deploy, and have your legal team review it before the shortlist is final.
How many concurrent editors can one document server handle?
There is no safe universal number, so ask for a sizing method and a load test on your own document mix. Concurrency depends on file size, number of sheets or slides, macros, embedded objects and the server's CPU and memory. Collabora's Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. For ONLYOFFICE Docs, the 9.4 release notes state that the Community Edition no longer has the 20 simultaneous connection limit, but the vendor's guidance on scaling and the Enterprise Edition's clustering features should still be confirmed for your load. A credible answer includes measured editors per pod, the test script, the document set and the latency targets used.
How is sticky routing by document configured in the load balancer?
Routing must send every editor of one document to the same editor pod, and the usual key for Collabora is the WOPISrc parameter. Collabora's Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replicas are set manually. It also says the load balancer must route by WOPISrc so all users editing one document reach the same pod, and it lists Nginx, HAProxy and OpenShift Router as supported ingress options. Ask the engineer to show the actual ingress or HAProxy configuration, the health check settings, and a test in which two users open the same file and confirm they reach the same pod. Ask what happens during a pod restart or node drain.
Which edition and support plan fits our user count?
The edition follows your user count, your support expectations and whether you embed the editor in your own product. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access, and an Enterprise plan for 100 or more users quoted with volume discounts. ONLYOFFICE lists admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support as Enterprise Edition features. Ask for a written quote tied to your exact user count, the service level terms in writing, the response times, and whether the Developer Edition applies if you embed the editor. The quote should separate one-time implementation fees from recurring subscription fees.
How are fonts and file formats tested on our own templates?
Ask the partner to run a fidelity test on a representative set of your real templates before any decision. A good test set includes your contracts, financial models, slide decks, forms and PDFs, with the fonts your organization actually uses, including any licensed corporate fonts. The partner should record pagination, table layout, tracked changes, comments, charts, embedded objects and macros for each file, and state the results in a signed report with the exact server version. ONLYOFFICE's README states that .docx, .xlsx and .pptx are native formats, and that PDF editing includes text, pages, annotations and form filling. Ask how fonts are installed in the container image, how missing fonts are handled, and whether the same fonts exist in offline builds.
How are updates signed, delivered and applied to the document server?
Ask how each update is verified before installation, who receives it, and how it is applied without breaking active sessions. Collabora's Business plan lists signed security updates and customer portal access, so confirm the signing method, the key distribution and the verification steps in the written runbook. For container deployments, ask for the image digest or signature check, the pinned version, and the rollback procedure. Ask how point releases such as the 25.04 branch point releases are tracked, how the partner tests a new version against your template set, and how changes are scheduled around peak editing hours. The answer should name the version, the change record and the rollback test.
How does the editor integrate with our file platform and identity system?
Integration runs through WOPI for Collabora and through the connector or API for ONLYOFFICE, and the file platform's version and configuration decide the work. Collabora lists WOPI integrations with platforms including Nextcloud, ownCloud, Seafile, Mattermost and others. ONLYOFFICE lists Nextcloud, ownCloud, Seafile and WOPI-compatible platforms. Ask the partner which file platform version they will connect, how the WOPI host discovery and access tokens are configured, how user identity flows from your directory, and how the editor is kept off public networks. For Nextcloud, the LDAP app and OpenID Connect or SAML backends are documented, and the Nextcloud Office configuration guide should be used as the baseline. Request a written integration test plan and a list of supported versions.
How to test concurrent editing and sticky routing claims
A vendor's per-server concurrency figure means little on its own. Ask which measured test produced the number, because the result depends on the document mix (small text files or large spreadsheets with formulas and embedded images), the pod resources allocated, and the load balancer in front of the editors. A figure measured on a large pod with small documents will not hold for a large pod with heavy spreadsheets, and a figure taken on a single node says nothing about how the routing layer behaves under load. Ask for the test script or method, the document set, the number of editors per document, the session duration and the pass criteria, and confirm whether the vendor ran the test on the same editor version you plan to deploy.
Collabora's Helm chart shows why routing is part of the claim. The chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replicas are set by hand, and that load balancers must route by the WOPISrc parameter so every user editing one document reaches the same pod. It also recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Ask the vendor to show a test in which two or more editors open one document through your ingress (Nginx, HAProxy or OpenShift Router are the supported options named in the chart) and confirm that co-editing, saving and copy and paste work, then repeat it while a second document is opened on another pod. Ask them to explain what happens when a pod restarts mid-session.
ONLYOFFICE 9.4 removed the 20 simultaneous connection limit from the Community Edition, according to the release announcement, and consolidated the server into a single process without RabbitMQ or database dependencies. That change alters the question. You should not assume the limit is gone for your scale, and you should not assume a fixed number either. Ask ONLYOFFICE or your partner to state the tested concurrency for your document mix, the hardware used, and whether features such as clustering and the admin panel, which the edition comparison lists under Enterprise Edition, are needed to meet your load. Require the partner to run your own pilot, with your documents, your routing and your peak schedule, and to record the results in writing before you accept any sizing.
Answers that should worry a buyer
Vendor and partner answers in an RFP often sound complete while hiding gaps in testing, licensing, routing, or support. The cards below pair each warning answer with the follow-up question that exposes whether the claim holds up under your conditions.
A single concurrency number
A bare figure such as "this server handles 100 editors" tells you nothing until you know the document size, the formats, the hardware, the proportion of active typers, and whether the test ran with co-authoring on. Ask for the test conditions behind any number and for results at your peak, not an average. Ask which pod resource limits the figure assumes. The Collabora Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, so ask whether the quoted capacity assumes that sizing.
Community builds sold as production-supported
Free community builds are a legitimate starting point, but they are not the same product as a supported release. Collabora describes its free CODE edition as not recommended for production, and the paid Collabora Online adds tested updates, security fixes and support. Ask the partner which edition they will deploy, who issues security fixes for it, and how long each branch is maintained. A partner that cannot name the edition has not finished scoping.
No statement of embedding license duties
Editing sessions inside your own portal or product can change your license obligations. ONLYOFFICE Docs Community Edition is AGPL-3.0, and ONLYOFFICE sells a separate Developer Edition under a commercial license for vendors that embed the editors in services they provide. Collabora's server code is MPL-2.0. Ask the partner to state, in writing, which license applies to each component, what source-sharing duties follow if you modify and offer the service, and whether your intended use needs a commercial edition.
Fidelity claims without your templates
Statements like "full Office compatibility" are not a test result. Fonts, table layouts, tracked changes, macros, and embedded objects behave differently across the ONLYOFFICE Office Open XML core and the LibreOffice-based Collabora engine. Ask for a fidelity test run on your own contracts, board papers, and spreadsheets, with the font set installed on the document server, and a written list of failures. Ask who fixes font gaps and how the server is kept consistent with the font set your users have.
Updates applied by hand, unverified
Editor servers receive security fixes, and a manual process with no integrity check is an unmanaged change to a system that holds your documents. Ask how each update is signed, where the signature is verified, who approves an update before it reaches production, and how a rollback works. For air-gapped or regulated deployments, ask how signed packages cross the boundary and how the partner records what was applied and when. Vague answers such as "we download and run the latest image" need a written process before award.
Autoscaling without a routing explanation
Autoscaling editor pods sounds efficient, but it can break a live editing session. The Collabora Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replicas are set manually. Load balancers must route by the WOPISrc parameter so every user editing one document reaches the same pod. Ask the partner to show the routing rule in their configuration, how it works behind Nginx, HAProxy or your own ingress, and what happens to open sessions when a pod restarts.
Vague ownership of the support contract
When an editing outage happens, the question is who answers the phone. Editor software, the file platform, the reverse proxy, and the partner's operations team may come from four different parties. Ask who holds the software support contract and at which edition level, what response times apply, who the escalation path runs to, and whether the partner's retainer covers upgrades and testing. Ask for the support terms in writing and check that they match the edition you are paying for, not a generic plan name.
How to score vendor responses
This table lists the weighted criteria for judging written bids on the same question set. Score each answer on whether the bidder can point to a document, configuration or test result you can verify, because sales statements carry no weight until they are backed by evidence.
| Criterion | What a strong answer states | Evidence required | Common gap |
|---|---|---|---|
| Platform fit and licensing (weight: high) | Chosen editor (Collabora Online or ONLYOFFICE Docs), the reason it fits your file platform, and the license that governs your deployment and any embedding | Written license statement, edition named, integration list for the file platform used, and a named WOPI or API connector version | Vendor names a platform without confirming the connector version or license obligations |
| Scale and routing (weight: high) | Concurrent editors per server or pod at stated resource limits, and how all editors of one document reach the same node | Sizing method with CPU and memory per node, sticky routing rule keyed to the document identifier (for Collabora, the WOPISrc parameter), load test report | Concurrency figure given without hardware, or routing described as session affinity with no document-level key |
| Edition and support (weight: high) | Edition matched to your user count, support tier, response targets, and what is covered for patches | Price list and terms for your user band, service level agreement text, support hours, named escalation path | Community or free build proposed for production, or support terms that are not in writing |
| Format and font testing (weight: medium) | Test method for .docx, .xlsx and .pptx files from your own templates, plus fonts and fallback behavior | Fidelity test results on your sample set, font inventory and install procedure, list of known rendering differences | Generic claim of Office compatibility with no tests on your files |
| Update security (weight: high) | How updates are published, verified and applied, and how they reach offline environments | Signed release process description, checksum or signature verification steps, documented upgrade and rollback runbook | Updates applied only by pulling the latest image with no verification step |
| Integration and delivery (weight: medium) | Delivery model, who operates each component, handover documents, and where your data and telemetry travel | Architecture diagram, responsibility matrix, list of outbound connections, sample handover pack | Operations left undefined after go-live or outbound traffic not disclosed |
What to ask about editions, support plans and user counts
Ask every bidder to split its quote into the parts that get paid for separately. The community build of Collabora Online or ONLYOFFICE Docs is free to obtain under its open-source license, so the money goes elsewhere: a vendor subscription or support plan for the editor, server and storage infrastructure that runs the document servers and file storage, integration work that connects the editor to your file platform through WOPI or an API, and implementation and testing services that prove fidelity, performance and updates work in your environment. A quote that bundles these into one number makes it impossible to compare a free build against a supported one, or to see which costs recur.
On the subscription side, the published Collabora Online pricing gives one reference point: the Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. Ask whether the price applies to named users or concurrent users, whether the support window matches your change calendar, and what happens when your count passes 99. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input, so ask for that quote in writing. For ONLYOFFICE, the edition comparison lists an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support as Enterprise Edition features. Confirm which of these you need, because the Community Edition is configured through config files only and gets support through GitHub and the forum.
Subscriptions recur, usually per user or per year, while integration, sizing, hardening, upgrade rehearsal and documentation are one-time project work, and server and storage costs recur on your own infrastructure. Request a quote from a written scope that lists the editor edition, user count, environments, integrations, support hours and deliverables. DeployOpen does not publish a price list, and its engagements are fixed-scope, so the quote follows from that written scope rather than from a rate card. Ask each bidder to state which support plan they assume, whether the price holds for a multi-year term, and what changes if your user count grows.
How to run a proof of concept before you sign
A proof of concept shows, on your own templates, network and file platform, whether Collabora Online or ONLYOFFICE meets the requirements in your RFP before any contract or production build begins. Each step ends with a recorded result that the evaluation team can compare side by side.
Select representative templates and fonts
Collect a set of documents that reflects real work: contracts, financial models, slide decks, forms and any PDFs your teams edit. Include the fonts your organization uses, plus any custom or licensed fonts, and note which files already show formatting drift in desktop Office. Your team owns this step because only your business users know which documents matter. It is done when the test set is frozen, each file is labeled by type and risk, and the font inventory is complete.
Install both editors from documented methods
Deploy Collabora Online and ONLYOFFICE Docs in a non-production environment using the installation method each vendor documents, such as Docker images, system packages or Kubernetes. Ask the vendor which edition you would run in production, because the free builds are not intended for production use and feature sets differ between editions. Your platform engineers or the implementation partner perform the installation. It is done when both servers start, pass their health checks, and the install steps, versions and configuration keys are written down so they can be repeated.
Test WOPI or API integration with the file platform
Connect each editor to the file platform you intend to use, for example Nextcloud or Seafile, through WOPI for Collabora or the documented integration path for ONLYOFFICE. Test opening, editing, saving, version history, permissions for view and edit roles, and the behavior when a user lacks rights. Confirm the exact integration version against the platform's compatibility notes. It is done when every test case in the integration script passes on both editors, and any gaps are logged with the workaround or the vendor response.
Run fidelity checks on the test set
Open and save every file in the test set in each editor, then compare the results with the originals. Check tables, tracked changes, comments, headers and footers, charts, embedded fonts, pagination and PDF form fields. Reviewers should be the people who use these documents daily. It is done when each file has a pass, minor or fail rating per editor, and the failing formatting elements are documented with screenshots.
Load test at the agreed concurrency
Using the number of concurrent editors per document and per server that your organization agreed in writing, run a scripted load test that simulates editing sessions on the same documents and on different documents. Measure CPU, memory, response times and dropped sessions on each editor's server, and confirm the routing behavior. Collabora's documentation states that load balancers must route by the WOPISrc parameter so all editors of one document reach the same pod, so test that routing explicitly. It is done when results show whether each server configuration met the target, with the limits and failures recorded.
Verify update signing and rollback
Ask each vendor to document how its updates are signed, how the signature is verified before installation, and how an update is rolled back if it fails. Apply a supported update to the test environment, verify the signature with the procedure the vendor provides, and then perform a rollback to the prior version. Confirm that documents edited before the rollback still open. Your security team should witness the process. It is done when the signature check and rollback have each been performed once and the steps are written into the runbook.
Record results and decide
Compile the fidelity ratings, integration results, load measurements, update procedure notes and support terms into one comparison document. Include the edition and support plan each vendor quoted for your user count, since the scope of support and signed security updates depends on it. Share the document with the evaluation team and decision makers. It is done when the team has a signed-off record of which editor passed each criterion, the open risks are assigned owners, and the remaining questions are sent to the vendors in writing before commercial terms are discussed.
What an implementation partner should show before a contract
Before you sign, a partner should hand you a written scope that names each deliverable, the platform version it covers, the systems it connects to (identity, file storage, WOPI hosts) and what is explicitly out of scope. Ask for named deliverables with acceptance criteria, not a general statement that the editors will be "installed and configured." DeployOpen works on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts, so the written scope is the document to compare across bidders. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and the scope should say which of those activities are included and which remain with your team.
The configuration record matters as much as the build. Ask for documented configuration covering the WOPI host settings, the load balancer rule that keeps every editor of one document on the same node (for Collabora, routing by the WOPISrc parameter), resource limits per pod or server, font installation and the list of formats tested. Ask for test evidence too: fidelity results on your own templates, concurrent-editing load results against the sizing you agreed, and a record of the tests run on each update. Ask who holds the test data and whether it can be reused in your own change process.
Finally, request an update and rollback runbook and a support model in writing. The runbook should explain how vendor updates are obtained, verified and applied, how a failed update is reverted, and which backups are taken first. The support model should state response expectations, who you call, and whether the retainer covers upgrades and continuous testing. DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Confirm that the partner will hand you the evidence packet in a form your auditor can review, and confirm what the partner will not provide.
How DeployOpen scopes, delivers and supports document editing evaluations
DeployOpen helps organizations answer document editing RFP questions with evidence from their own environment rather than vendor claims alone. We plan, implement, test, document and support self-hosted editing inside your own cloud accounts, data centers or air-gapped networks, under a written scope agreed before work starts.
How we scope
- We confirm which editor, Collabora Online or ONLYOFFICE Docs, fits your file platform, WOPI needs and user count.
- The written scope lists concurrent editor targets, edition choice, support plan, font and format test set and update procedure.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We deploy the editor and document server in your infrastructure, with WOPI routing that keeps each document on one node.
- We test Office file fidelity, fonts and PDF handling against your own templates and record the results.
- We document how signed updates are verified and applied, and configure AI features to the default you approve.
How we hand over
- You receive architecture diagrams, configuration records, load test results and the sizing rationale behind them.
- Runbooks cover patching, backup, restore, scaling and the steps to take in a security incident.
- Compliance evidence is prepared for your assessors, who decide what it proves, since DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers cover tracking of new editor releases, edition or support plan changes, and re-testing of fidelity after upgrades.
- Quotes follow from the written scope, so ask us to state which items recur and which are one-time.
