The Migration Question
The most common blocker we hear from teams considering a switch to Quaterio is not pricing, features or learning curve. It's migration:
"We have fifty templates in Word. Are we supposed to rebuild them all by hand?"
The honest answer used to be yes. Document migration is a hard problem and most tools fail at it loudly: imports come in as flat HTML with no structure, fonts are wrong, tables are mangled, page breaks are missing. The result reads worse than rebuilding from scratch, which is what most teams end up doing anyway.
So we added a document import pipeline that handles the common cases without that pain. It accepts Word (.docx) and PDF files and converts them into editable Quaterio documents while preserving structure, headings, tables, lists and basic formatting. This post walks through what it does, what it doesn't, and when to use it.
The Easy Path First: Just Copy and Paste
Before you reach for the import pipeline, try the easier thing: open your Word document, select all, copy, and paste into a blank Quaterio document. The editor is built on Tiptap, which has solid paste handling for Word and Google Docs content. Most of what you'd expect to survive does:
- Headings keep their level
- Paragraphs keep their inline formatting (bold, italic, links)
- Bulleted and numbered lists land as actual list blocks, not as text with bullet characters
- Tables paste in with rows and columns intact, including headers
This works on every plan including Free, because there's no pipeline involved. The browser hands the editor the clipboard contents and Tiptap normalizes them into blocks.
A useful follow up if your paste lands as one big HTML block: right click on the block in the preview and pick "Split into Blocks". The editor walks the HTML, breaks it apart, and gives you separate heading blocks for each <h1> through <h6>, separate image blocks for each <img> or <figure>, separate horizontal rule blocks for each <hr>, separate page break blocks where they appear, and groups the remaining content into HTML blocks at natural break points. Org default fonts and colors apply to the split heading blocks automatically. This is the move when you want granular control over each section instead of one wall of content.
Where copy and paste falls down: images aren't part of the clipboard payload from Word, so they don't come along. Footnotes get inlined as plain text. Headers, footers and page breaks are not paste content, they're document chrome that lives outside the body. Multi column layouts flatten to one column.
So the paste path is the right starting move for:
- Single documents you're migrating one at a time
- Documents that are mostly text plus the occasional table
- Quick experiments to see if a Word document is even worth keeping as a template
The pipeline below is for everything paste can't handle, mainly bulk migration, PDFs (you can't usefully paste from a PDF), and documents where the images and headers matter.
What the Pipeline Actually Does
The import lives at /dashboard/[org]/document-import in the app. Upload a file and the pipeline:
- Parses the document into a structured representation. For DOCX, that's the underlying XML. For PDF, the parser extracts text, paragraph boundaries, tables, lists, headings and images using layout aware analysis.
- Converts the structured representation into Quaterio's block format. Each detected element becomes a block of the appropriate type, heading, paragraph, table, list, image.
- Opens the result in the editor as a draft document, ready for review and cleanup.
The pipeline is on the Pro plan for DOCX and PDF source files. The Business plan adds advanced import with deeper layout detection for more complex source formats.
What Survives the Import
For most business documents, the following survives cleanly:
- Headings at H1 through H6, recognized from the source's style information and mapped to Quaterio heading blocks. Hierarchy is preserved.
- Paragraphs, text content with basic inline formatting (bold, italic, links).
- Lists, both ordered and unordered, including nested lists up to three levels deep.
- Tables, including header rows. Cell content keeps inline formatting. Complex tables with merged cells survive structurally, though may need light touch up.
- Images, extracted from the source and embedded again as image blocks in Quaterio.
- Page breaks, explicit page breaks in the source become page break blocks.
For business reports, contracts, proposals and similar structured documents, this covers about 80% of what's on the page. The remaining 20% is cleanup work, not a rebuild.
What Needs Cleanup
Some elements don't survive cleanly. Knowing the list before you import saves frustration:
- Custom typography. Source fonts that aren't in Quaterio's font picker get mapped to a sensible fallback. If you used a specific font for branding, you'll want to apply again it from the brand kit after import, or accept the fallback.
- Headers and footers. Source headers and footers are detected but not always perfectly. The pipeline pulls them into Quaterio's header/footer configuration as a starting point; expect light editing.
- Complex layouts. Multi column layouts, text wrapped around images, and absolutely positioned elements may flatten to single column. Quaterio's pagination engine handles two and three column layouts natively, but the import isn't always smart enough to detect them. Easier to add back columns in the editor than to fight the import.
- Forms and fillable fields. PDF form fields are detected as text, not as Quaterio's form field placeholders. Recreate them via the form field block if you want them interactive in the export.
- Footnotes and endnotes. Currently flattened into paragraph text in line with the reference, with the marker preserved. If your source relies heavily on footnotes, this is the cleanup that takes longest.
For most migrations, the pattern is: import the document, spend ten to thirty minutes per file cleaning up the items above, then save as a template. Once it's a template, future variants are produced via template variables, no manual editing.
DOCX vs PDF: Use DOCX When You Have It
If you have both the DOCX source and the rendered PDF for the same document, always import the DOCX. The DOCX preserves:
- Heading styles and outline hierarchy
- Exact paragraph boundaries
- Native list structures (with semantic nesting)
- Tables with row and column relationships intact
- Embedded image references at the correct positions
PDF import is layout driven. It looks at where text sits on the page and reconstructs paragraphs, lists and tables from spatial proximity. That works well for visually clean documents but struggles with:
- PDFs that were scanned (no actual text, just images of text)
- Highly designed marketing PDFs with overlapping text and images
- PDFs with two column layouts that the parser sees as one long column with awkward breaks
For scanned PDFs, you need OCR first to turn the images into actual text. We don't run OCR in the import pipeline, it adds significant processing time and the off the shelf options have wildly varying quality. The standard pattern is: run OCR locally (Tesseract, Adobe Acrobat, or a cloud service), save the OCR'd version, then import that.
Batch Import for Many Files
If you're migrating ten or more templates from Word to Quaterio, doing it through the UI gets tedious. The Business plan exposes the import via the REST API, so you can wire up a script that walks a directory of DOCX files and creates a Quaterio document per file.
The end to end migration script for an agency moving from Word looks roughly like:
# Pseudocode
for file in templates/*.docx; do
curl -X POST https://quaterio.com/api/v1/documents/import \
-H "Authorization: Bearer $QUATERIO_TOKEN" \
-F "file=@$file" \
-F "asTemplate=true"
done
Each call returns a document ID. The output is a folder of imported drafts ready for review. From there a single pass through each one for cleanup takes longer than the import itself.
When Importing Is Not the Right Move
Some files are better rebuilt than imported. Honest cases:
- The original was a mess. If the source document has inconsistent heading styles, manually applied formatting instead of styles, and tables built out of tabs, the import will reproduce that mess. Rebuilding lets you adopt the right structure once.
- You're consolidating multiple sources. If "the template" is currently five different Word files that drift over time, the value of switching to Quaterio is having one canonical template. Importing all five and picking the best parts of each is rebuild work either way.
- You want to redesign as part of the move. Migration is a natural time to redo branding, simplify structure, drop unused sections. If you're going to do that anyway, the import isn't saving you much.
For these cases, the free template library is a faster starting point. The business report template and project proposal template are pre structured for the most common business document types.
What Happens After Import
The import gives you a document. Most teams want a template, a reusable layout with variable placeholders that produces personalized PDFs. The two are different.
A document is a one off. You edit it directly and export a PDF.
A template is a layout where specific fields are placeholders ({{client_name}}, {{date}}, {{total}}) that get filled in when you generate a PDF, either through the editor or via the REST API. For batch generation across hundreds of clients, this is the difference between thirty seconds of work and three hours.
Converting an imported document into a template is a separate step: open the document, identify the parts that should vary per use (client name, project specifics, dates, pricing), and replace them with variable placeholders via the editor's variable block. Save the result as a template. Future variants take seconds.
Try It
Sign up free to test the import pipeline on a single file at no cost (the Pro plan is required for ongoing imports beyond the trial).
If you're evaluating Quaterio as an InDesign alternative, the migration question is usually the blocker. Importing your existing Word and PDF source files is the first step. From there, the template library and the editor handle the work going forward.