Moving off Carbone

Why teams move

• PDF output goes through LibreOffice, so fidelity depends on how faithfully it renders your document — and that is a separate program with its own layout opinions between your template and the file a customer sees.
• Word is a page-oriented editor but not a precise one. Documents that must hit an exact position on a page are harder to pin down than in a system where the layout contract is explicit.
• Running it yourself means operating LibreOffice in production — a heavy dependency to install, sandbox and keep patched.
• Word templates are hard to review. A layout change arrives as a modified binary, so there is no meaningful diff and no small pull request.

The checkable parts

Claims worth verifying rather than taking on trust — each links to its source, checked July 2026.

• Templates are docx/odt with mustache-style `{d.x}` markers; PDF conversion requires LibreOffice.

  carboneio/carbone on GitHub ↗

What is different here

When to stay with Carbone

It is often the right answer. If any of these describe you, this is not a migration worth making.

• Your document authors work in Word and would not accept anything else. That is a real constraint and Carbone respects it better than this product does.
• You need xlsx, docx or pptx output, not just PDF. This product renders PDFs only.
• You want an open-source core you can run and modify yourself, with no third party in the document path.

What moving involves

1. 1 A .docx can be imported directly and converted into a template with a schema, so an existing Carbone template is often the starting point rather than a rewrite.
2. 2 The JSON you already pass maps closely — `{d.field}` markers and schema fields are the same idea with different syntax.
3. 3 The LibreOffice dependency comes out of your infrastructure with it.

The API reference covers authentication, the render call and error handling; the template gallery has designs to start from rather than a blank page.

Other migrations