Replacing JODConverter and unoconv with the Collabora Online conversion API: what the move involves
Moving server-side conversion off JODConverter or unoconv scripts is mostly a change of conversion backend, followed by testing whether the output still meets your standard. Consider a team that runs unoconv or a JODConverter service to produce PDFs or other formats for an application, such as invoices, reports or generated letters. The application code calls the converter, the converter starts a LibreOffice process, and the result is returned or stored. The migration keeps that contract in place and changes what sits behind it, so the work concentrates on the call sites and the output checks rather than on the application's business logic.
There are two documented paths. The first is the Collabora Online REST convert-to endpoint, which accepts an HTTP POST of the file at /cool/convert-to/<format>, so your code sends the document and receives the converted file in the response. The second is JODConverter's Collabora backend, available in newer JODConverter versions, which uses a running Collabora Online server instead of driving LibreOffice directly. The second path suits teams that already call JODConverter and want to change only its configuration. Confirm the JODConverter version you need with its project documentation before choosing it, and check the endpoint behavior for every output format you produce, because the set of supported formats and filters is defined by Collabora's implementation rather than by your existing scripts.
Which JODConverter and unoconv capabilities map to Collabora Online
This table compares common conversion calls from JODConverter and unoconv scripts with their Collabora Online equivalents and flags what the supplied documentation does not confirm. Read the right-hand column as a migration note: where a row says verify, test that behavior in a pilot with your own documents before you remove the old path. The main takeaway is that the basic convert-to call maps directly, while filter options, fonts, macros and templates need explicit testing rather than an assumed match.
| Capability | JODConverter or unoconv today | Collabora Online equivalent and migration note |
|---|---|---|
| Single file in and out | Script or service passes one input file and one target format to LibreOffice and returns the output | POST the file to the convert-to endpoint with the target format in the path. Confirm the response handling in your client matches the new endpoint. |
| Format pairs | Pairs such as docx to pdf or xlsx to csv are set by the target filter name or extension | Target format is set in the /cool/convert-to/<format> path. Verify each input and output pair your workload uses, including legacy and Visio inputs. |
| Batch jobs | Scripts loop over a directory and start a conversion per file, often with a new office process each time | Persistent processes replace the start, convert and shut down cycle, which changes throughput. Verify concurrency limits and queueing with Collabora before sizing a batch run. |
| Custom filter options | Filter strings or options passed to LibreOffice, such as export settings for PDF or CSV delimiters | Not confirmed by the supplied documentation. Test every filter option you use and compare output against your baseline files. |
| Fonts | Fonts come from the host operating system and any fonts installed for the LibreOffice profile | Font availability depends on the container or host where Collabora runs. Verify that the fonts in your documents are present, and plan for a font set in the image or host. |
| Macros | Macro execution is possible in some unoconv or custom LibreOffice setups | Do not assume macro parity. Confirm with Collabora how macros are handled in the conversion path and test any macro-dependent documents separately. |
| Template fill | Mail merge or placeholder replacement is often handled by a script before or after LibreOffice runs | Template filling is not confirmed as a conversion-endpoint feature. Keep the fill step in your own code unless a pilot shows the output matches. |
Documented conversion paths and the tools that support them
Two documented routes can replace JODConverter and unoconv scripts for server-side conversion: calling the Collabora Online REST endpoint directly, or pointing a newer JODConverter release at Collabora Online as its backend. Each card covers one part of that choice, from the call pattern to the operating responsibility and the existing setup you keep.
Collabora Online REST convert-to endpoint
The convert-to endpoint at /cool/convert-to/<format> accepts an HTTP POST of the source file and returns the converted document. Your application or job runner calls it directly, so no JODConverter layer sits in between. Your team owns the HTTP client, retries, timeouts and file handling. Check how your existing scripts pass file names, handle failed conversions and set request timeouts before mapping them to this call.
JODConverter Collabora backend
Newer JODConverter versions include a backend that sends work to Collabora Online instead of starting LibreOffice directly. If your application already calls JODConverter's Java API or its REST wrapper, this path can keep those call sites and change only the backend configuration. Confirm which JODConverter release includes the backend, which Collabora Online version it expects, and how it authenticates to the server before you upgrade.
Collabora document conversion guide
Collabora's document conversion guide is the reference for the supported formats, the request shape and the comparison between Collabora Online, JODConverter and unoconv. Use it as the source for every endpoint detail in your design, and record the guide version you built against. Re-read it at each Collabora Online upgrade, because request handling and supported formats can change between branches.
Who operates the conversion service
With the REST path, your platform team runs the Collabora Online server, its updates and its capacity, while the application team owns the calls. With the JODConverter path, the same server sits behind a Java service that your developers maintain. Decide early which team is paged when conversions stall, and whether the conversion servers are shared with a document editing deployment or kept separate.
What your existing setup carries over
Your current JODConverter or unoconv setup holds the format list, the file naming rules, the timeout values and the queue or retry logic, and most of that carries over. The conversion engine itself changes, so output differences in fonts, page layout and embedded objects must be tested against your sample documents. Inventory these pieces before cutover so you know what to rewrite and what to keep.
How Collabora's isolation and persistent processes change conversion reliability
Collabora states that its conversion runs in an isolated environment, using chroot jails, seccomp-bpf system call filtering and a sparse filesystem without a shell, and that it uses persistent processes rather than a start-convert-shutdown cycle. That second point is the one that changes operations most. JODConverter and unoconv scripts typically start a LibreOffice process for each job, so a hung conversion usually ends when the script's own timeout kills it and a fresh process takes the next job. With Collabora Online's /cool/convert-to/<format> endpoint, the conversion engine stays resident between requests, so a stuck or memory-heavy document can affect later requests served by the same process. Plan timeouts, memory limits and restart behavior with that in mind, and ask Collabora or your own tests how the service recovers from a crashed conversion worker without dropping unrelated requests.
Memory is the first thing to measure. A persistent process accumulates state over time, so a long-running instance can look healthy after a restart and degrade under a steady mix of large spreadsheets and presentations. Run a soak test with a representative document set, record resident memory per process and per container, and compare the trend against the limits you set in the deployment. If you run the Helm chart, the README's production figures (8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB) are a starting point for sizing, not a result you can assume for your workload. Set client-side timeouts that exceed the slowest legitimate conversion you have seen, and make sure your retry logic does not resubmit a document that is still being converted, which would double the load on a single process.
The isolation claims are vendor statements, so verify them before relying on them for document handling you are accountable for. Confirm in your own environment that the container or host runs the seccomp profile and capability settings you expect, that the conversion worker cannot reach internal networks or read files outside its working area, and that failed conversions produce errors your application can distinguish from successful output. Add monitoring for process restarts, queue depth and error rates from the conversion endpoint, because a persistent service fails quietly unless someone watches it. Treat the isolation model as one control among several: the input files still come from users and other systems, so validation, size limits and malware scanning remain your responsibility.
The sequence from inventory to cutover with a parallel run
This sequence moves server-side conversion from JODConverter or unoconv to the Collabora Online conversion API in controlled stages, so each conversion path is proven against the old output before any traffic depends on the new one.
Inventory every conversion call site
Your team lists every place that calls a conversion script or JODConverter, including applications, cron jobs, document pipelines and report generators. For each call site, record the input formats, the requested output formats, the expected volume, the calling service and the owner. Include conversions triggered indirectly, such as previews, thumbnails and PDF generation for archiving. The step is done when every call site has an owner and every input and output pair is written down in one inventory that the migration team has signed off.
Map each pair to the new endpoint
For each input and output pair in the inventory, your team confirms whether the Collabora Online REST endpoint at /cool/convert-to/<format> can produce it, or whether the JODConverter backend that uses Collabora Online is the better fit for an existing Java integration. Mark anything without a confirmed path as an exception for the pilot. The output is a mapping table that names the target format, the request method and the owner for each pair, with exceptions listed separately so they are not discovered during cutover.
Pilot against a representative document set
Your team assembles a document set that reflects real production inputs, including the awkward cases such as embedded fonts, large spreadsheets, complex tables, tracked changes, and files produced by older Office versions. They run each sample through both the old script and the Collabora Online endpoint and review the results manually for layout, pagination, fonts and metadata. The pilot is complete when every exception from the mapping step has a recorded decision: fix, accept with a known difference, or keep the old path for that pair.
Run both backends in parallel
The production application sends each live request to the existing backend, which remains the source of truth for users, and also to the Collabora Online endpoint, whose output is stored separately and never shown to users. A comparison job checks file type, page count, text extraction, failure rates and processing time for each pair. Your team reviews mismatches daily and records each cause. The parallel run is complete when the mismatch categories are understood and the remaining differences are accepted in writing by the document owners.
Cut over behind a feature switch
Your team routes conversion for one call site at a time through a configuration switch that selects the old or new backend, starting with the lowest-risk pair. Each switch change is logged with the operator, the time and the rollback procedure. Failed conversions on the new path fall back to the old backend during the transition, and fallback events are counted. The cutover step is complete when every pair in the inventory runs on the new backend and fallback events have fallen to a level the owners accept.
Decommission old scripts and LibreOffice workers
After a stable period agreed with the document owners, your team removes the unoconv scripts, the JODConverter service configuration that is no longer used, and the LibreOffice worker processes and their container images. Secrets, service accounts and firewall rules that existed only for the old path are revoked. The step closes with an updated architecture record, a runbook for the Collabora Online conversion service, and a short note confirming what was removed and when, so that the old path cannot be restarted by accident.
What drives the effort and cost of replacing conversion services
This table lists the main drivers that change the effort and cost of moving server-side conversion from JODConverter or unoconv to Collabora Online. Read each row for whether the cost is one-time or recurring and what to ask a partner to price explicitly in a written scope.
| Driver | Why it changes effort or cost | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Number of call sites | Each script, service or application that calls a conversion must be found, mapped to a target format and repointed to the new endpoint or backend. | One-time | A list of call sites with owners, the conversion calls each makes, and the test cases assigned to each. |
| Output formats and fidelity requirements | Converting to PDF is usually simpler than converting between Office and OpenDocument formats where layout, fonts and embedded objects must match. | One-time, with recurring checks after upgrades | Named input and output format pairs, the fidelity criteria used to accept them, and who signs off each pair. |
| Custom fonts and templates | Documents that depend on fonts or templates missing from the conversion host produce different pagination and glyphs, which needs font installation and comparison testing. | One-time to set up, recurring when fonts change | Font inventory, licensing confirmation for each font, and the process for adding fonts to future container or package images. |
| Macros and embedded content | Macro-enabled files, linked objects and embedded spreadsheets may need a decision on what is converted and what is rejected, which affects the test set. | One-time | Inventory of macro-enabled and embedded inputs, and the handling policy the provider will implement and test. |
| Volume and concurrency needs | Batch conversions, peak periods and parallel requests determine how many persistent conversion processes or replicas are needed and how queues are monitored. | Recurring, as load grows | Expected peak and average request rates from your own logs, the queueing and timeout behavior to be built, and load test results. |
| Deployment model | Docker images, system packages or Kubernetes each require different service units, health checks, resource limits and upgrade procedures. Collabora's Helm chart sets manual replica counts and per-pod resource guidance. | One-time to build, recurring to operate | The chosen model, the resource requests and limits to be set, and who maintains images or packages after handover. |
| Isolation and reliability changes | Moving from start-convert-shutdown runs to persistent processes changes how crashes, memory growth and restarts are detected and handled. | One-time to design, recurring to monitor | Monitoring and alerting design, restart and recovery behavior, and evidence from failure tests. |
| Testing and sign-off | Regression testing across formats, the number of stakeholders who approve results, and the evidence needed for audit or compliance reviews set the duration of the project. | One-time, with recurring regression runs on each update | Test plan, acceptance criteria, sign-off roles, and whether regression testing is included in ongoing support. |
What usually goes wrong when conversion moves to Collabora Online
Moving conversion from JODConverter or unoconv to a persistent Collabora Online service changes how output, isolation, capacity and operations behave. The risks below share one root cause: the old scripts treated each job as disposable, and the new service does not. Check each one before cutover, not after users report it.
Subtle layout changes in PDF output
Conversion output can shift in pagination, table widths, image placement and line breaks when the rendering engine or its version changes. Some of these shifts are too small to notice in a sample but matter for contracts, invoices or regulated forms. Prevention: build a fixed corpus of representative documents, convert them with the old and new paths, and compare the PDFs page by page before switching any workflow over.
Font substitution in converted files
If a font used in a source document is missing on the conversion host, the output silently substitutes another face, which changes metrics and can reflow whole documents. Old JODConverter hosts often had a different font set than the new Collabora host, so the mismatch can appear only after migration. Prevention: inventory the fonts used in your document corpus, install the same families on the Collabora host, and confirm the font list is part of the build record.
Timeouts under concurrent load
A single persistent process handles many requests, so a burst of large conversions can queue behind each other and push callers past their HTTP timeouts. Callers that worked against a pool of short-lived LibreOffice instances may retry aggressively and make the queue worse. Prevention: load test with your largest real files at your expected peak, set client timeouts and retry limits explicitly, and decide where a conversion backlog should surface to users.
Unsupported input formats
Collabora Online documents support for OpenDocument, Microsoft formats such as docx, xlsx and pptx, PDF, RTF, CSV and Visio. Scripts that convert legacy binary formats, older Office variants, or file types handled only by a custom filter can fail or produce partial output. Prevention: list the input types your jobs actually receive, test each one against the convert-to endpoint, and reject or route unsupported types before they reach the service.
Assuming per-job isolation still applies
Unoconv and many JODConverter setups started a fresh office process per job, so a crash or hostile file ended with that process. Collabora runs persistent processes, so state, memory growth and a malformed file can affect later jobs unless the service is restarted and sandboxed correctly. Prevention: review how isolation is enforced in your deployment, keep the service off shared hosts, and define restart and recycling rules that do not depend on per-job cleanup.
No monitoring for a persistent service
A long-running conversion service can fail slowly, through memory growth, stuck workers or a degraded queue, while the process still answers health checks. Scripts that failed loudly on each job gave operators an easy signal that no longer exists. Prevention: monitor request latency, error rates, memory and process counts, and alert on conversion failures from the calling application, not only on whether the port is open.
Questions teams ask before replacing JODConverter or unoconv
How much effort and cost does replacing JODConverter or unoconv involve?
The effort depends mostly on how many conversion call sites you have, how varied the input formats are, and how much of the current pipeline depends on local LibreOffice behavior. Cost has two parts: the people who change and test the code and the infrastructure that runs Collabora Online. Most of the work is inventory and testing, not the endpoint swap itself. Ask any partner to price each call site, the test corpus, the isolation design and the operating runbook as separate line items so you can see what is one-time and what recurs.
What drives the timeline for moving server-side conversion to Collabora Online?
The timeline is driven by the number of conversion paths, the formats they handle, and how quickly your team can review converted output. Work that often takes the longest includes checking fidelity of Microsoft formats such as docx, xlsx and pptx, reproducing timeouts and error handling, and agreeing who signs off on output quality. Deployment of the server itself is usually the shorter part. Ask for a schedule tied to named milestones, such as inventory complete, test corpus passed and cutover, rather than a single end date.
What must our team provide before a conversion migration starts?
Three inputs make the biggest difference to scope and accuracy:
- A representative set of sample documents, including the awkward ones such as large spreadsheets, embedded fonts and templated files.
- A call inventory listing every service, script or job that invokes JODConverter or unoconv, the target formats and the expected response handling.
- Named test owners in the business who can judge whether a converted PDF or file is acceptable.
If these are missing, the quote should say so, because estimates without them carry more uncertainty.
Can our internal team replace JODConverter or unoconv without outside help?
Yes, a capable internal team can do this, especially if it already runs Collabora Online or LibreOffice-based services and has Docker or Kubernetes operations experience. The usual gaps are not in the conversion call itself but in isolation design, load behavior under concurrent requests, and a repeatable fidelity test suite. Decide early which of these your team will own after go-live. An outside partner can take the build, the test harness or a fixed-scope handover, and your engineers can keep the operating role.
Does the Collabora Online license tier matter for server-side conversion?
It can. CODE is the free edition, released roughly once a month as a rolling release, and Collabora describes it as suited to testing, home use or small teams but not recommended for production. For a conversion service that other systems depend on, the Business plan is listed at 3 euros per user per month for up to 99 users, and it includes long term support, a service level agreement, signed security updates and customer portal access. Confirm with Collabora how the per-user count applies to a server-side service with no interactive users, and whether an Enterprise quote fits better.
How should we compare outside quotes for this work?
Compare quotes on the written scope, not the total. Each quote should list the call sites covered, the formats and fidelity tests included, the isolation and deployment design, the handover plan, and the support terms after go-live. Check whether the quote assumes Collabora Online subscription costs or leaves them to you, and whether ongoing security updates are priced separately. DeployOpen does not publish a price list and quotes follow from a written scope, so ask every provider for the same scope definition to make the numbers comparable.
What should engineers check on the new conversion service before cutover?
Engineers should test the endpoint with the sample corpus, then load it with realistic concurrency and confirm that timeouts, retries and error codes match what the calling systems expect. Verify that the service runs in an isolated environment and that the rules for network access and file handling match your security baseline. Collabora states its conversion runs with chroot jails, seccomp-bpf system call filtering and a sparse filesystem without a shell, using persistent processes rather than a start-convert-shutdown cycle. Confirm those properties in your own deployment rather than assuming them.
How DeployOpen scopes and delivers a conversion migration
DeployOpen starts every conversion migration with a written, fixed scope that names the conversion paths being replaced, the document types each path handles, the callers that send files today, and the deliverables and timelines both sides agree to before work begins. For this move, the inventory is the first deliverable. It lists every JODConverter instance, every unoconv script and every cron job or application call that posts files for conversion, along with the target formats and the systems that consume the output. Without that list, a scope cannot be priced or timed honestly, so DeployOpen treats it as a gating step rather than an assumption. Clients should ask for the inventory to be part of the quote, and should confirm with their own application owners which callers are still in use.
On the build side, DeployOpen installs and hardens Collabora Online inside your infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. The work covers the chosen deployment method, the reverse proxy and TLS configuration, the access controls that decide which services may call the convert-to endpoint, and resource settings sized against the measured conversion load rather than guesses. Where JODConverter is moving to its Collabora backend, DeployOpen also handles the application-side configuration changes. Test evidence is prepared as part of delivery: sample conversion runs per format, output comparisons against the current pipeline, failure and timeout handling, and the logs and settings needed for your own change records. Those artifacts help your internal reviewers and assessors, but DeployOpen does not issue audit reports or certifications.
After cutover, support does not end at handover. Many teams keep an ongoing relationship through a retainer for support, Collabora Online version updates and periodic re-testing of conversion output when the vendor ships a new release. Pricing for that retainer is set from its own written scope. For a conversion migration, ask any partner, DeployOpen included, to state in writing who owns the test corpus after delivery, how security updates to Collabora Online are applied and tested, and what happens to the old conversion services once they are switched off. Confirm these answers with your own security and operations leads before signing.
