InDesign is a layout tool, not a content model — which makes InDesign to DITA conversion one of the hardest migrations in technical publishing. DocentraX handles the full journey, conversion, migration and transformation, turning InDesign's HTML export into clean, valid DITA and reconstructing the topic structure the layout never captured, so your editorial content becomes reusable, single-sourced and ready for every channel — including the printed page it started on.
Content authored in InDesign is content optimised for exactly one output — a printed page or a fixed PDF — and hostile to every other. There is no topic structure, no reuse, no single-sourcing; a change means editing a layout, and republishing to a new channel means redoing the design. The words are valuable; the container makes them a dead end.
Extracting them by hand is slow and error-prone precisely because what InDesign exports is a description of a page, not a description of a document. The nesting exists to hold type in position, and the style names attached to your paragraphs describe how text should look rather than what it means — so your actual content sits buried under page furniture. Most migration quotes price this as a manual, per-page services engagement. An InDesign to DITA conversion that reads that export for what it is, and rebuilds real structure from it, is the difference between a cleanup project and a clean start. This is why DITA migration services that treat the export as one whole publication beat topic-by-topic re-keying every time.
InDesign optimises content for one page. DITA optimises it for everywhere else.
We read an InDesign export the way someone who knows InDesign would read it: we can tell a genuine InDesign export from ordinary web markup, and we know which parts of it are layout scaffolding to be discarded and which parts are your editorial content to be kept. An InDesign export carries no table of contents, so reading order follows the sequential file and folder order the export itself was written in — the order the publication was written out, front to back — and the free sample conversion is where we confirm that sequence matches the book before a full run. From there the pipeline rebuilds real DITA semantics: heading levels become a topic hierarchy, procedures become tasks, tables become CALS tables with their spans intact, and notes, cross-references and images are carried across as proper elements. How deeply we infer that hierarchy is tuned to your content rather than fixed, the typographic detail of a print source survives the trip, and your paragraph styles are mapped to meaning by rules agreed with you instead of guesswork. Content conservation is absolute: structure degrades gracefully where it genuinely cannot be inferred, but no text is ever dropped.
Then there is the harder case, and for InDesign it is the normal one: an export that carries no headings at all. The hierarchy your readers see lives entirely in the styling — styled paragraphs rather than h1 to h6 — and a generic converter turns that into one flat, meaningless topic. When that is what arrives, we rebuild the heading outline from the visual evidence itself: font size measured against the body text, bold weight, ALL-CAPS and centred openers, heading-like style names, and the enumeration patterns print books actually use — CHAPTER I, PART 1, 1.2.3. How deep that reconstruction goes is tunable, and a document that already carries real headings is left alone or gap-filled, never rewritten. Rebuilding headings that do not exist — not merely reading ones that do — is the difference between a converter built for InDesign and one that happens to accept its files.
Every InDesign to DITA migration runs the same five-stage lifecycle, applied to the specifics of a layout-only source.
Confirm the source really is an InDesign export, establish reading order from the export's own file and folder sequence, and inventory every piece of content, every image and every style in use — so you know exactly what you have before anything is transformed.
Infer structure from your heading levels — or, where the export carries none, rebuild them from the styling evidence described above — and map it to a DITA topic hierarchy — procedures to tasks, tables to CALS, notes, cross-references and images rebuilt as real elements — while InDesign's layout scaffolding is stripped away.
Apply your metadata, keys, IDs and naming conventions, and optionally run Knowledge Fabric to write keywords into topic prologs.
Run the DITA completeness check against your own schema — DTD validation, your specialization's DTDs included, plus links, conref, keyref, image references, duplicate ids and keys, circular maps — before anything is delivered.
Output topics and a map in exactly the structure your platform expects, with folder layout, asset foldering and every reference intact.
A generic run gives you valid DITA with inferred structure, generic infotypes and generated IDs — a correct starting point that still reflects the source rather than your model. A customer-specific InDesign to DITA conversion aligns the output to your standard. For a layout-only source that means, concretely:
Because that tailoring is configuration agreed once rather than bespoke work repeated for every book, the same rules apply consistently to everything you send afterwards. Without it — and with a layout-only source the gap is at its widest — your team is left turning style names into meaning by hand, one paragraph at a time.
| Your concern | How we answer it |
|---|---|
| The export is layout, not structure. | We discard the page furniture and rebuild a genuine topic hierarchy from your headings, so what lands in DITA is content rather than positioning. |
| There is no table of contents to give reading order. | Reading order follows the export's own sequential file and folder order — the order it was written out — and the free sample conversion is where you confirm the sequence before the full run. |
| We cannot afford to lose any editorial content. | Content conservation is zero-tolerance: structure may degrade gracefully, text is never dropped. |
| It has to drop into our CCMS, not a generic DITA shape. | Customer-specific rules map to your specialization, metadata, IDs and DTD before delivery, so it lands ready to work in Heretto, Paligo, IXIASOFT or Tridion Docs. |
DITA is the OASIS open standard for topic-based technical content, and its value — single-sourcing, conref and keyref reuse, conditional publishing with ditaval, and multi-channel output through the DITA Open Toolkit — depends on clean migration. InDesign is one of the hardest sources precisely because it carries no document structure at all. Teams usually re-key the content, hand it to a services firm, or run a generic HTML scraper that produces flat, meaningless topics. What sets DocentraX apart is that we treat an InDesign export as an InDesign export rather than as anonymous markup: reading order is established where there is no table of contents to supply it, and a topic hierarchy is reconstructed that the source never actually had — all inside a single DITA conversion pipeline rather than a point tool bolted on to a manual process.
If your HTML did not actually come from InDesign, the same engine covers it: see our HTML to DITA conversion for markup of unknown origin, or Word to DITA conversion if the editorial source still exists as Word.
Content freed from InDesign becomes real, structured DITA: single-sourced, reusable with conref and keyref, conditionally publishable, and deliverable to any channel through the DITA Open Toolkit — including, once again, print. The design was one destination; now the content can reach all of them, and it lands in your CCMS ready to work rather than waiting on a queue of manual cleanup.
DocentraX takes InDesign's HTML export and reads it for what it is — a description of pages, not of a document. We confirm the source is genuinely an InDesign export, take reading order from the sequential file and folder order the export itself was written in, and rebuild a topic hierarchy from your headings — reconstructing them from the styling itself when the export carries none. Procedures become tasks, tables become CALS tables with their spans, and notes, cross-references and images become proper DITA elements. The result is validated against your own schema before delivery.
Yes. InDesign exports carry no table of contents, so reading order follows the sequential file and folder order the export was written in, front to back, and topic nesting is inferred from your heading levels — or rebuilt from the export's styling when no headings exist at all. How deep that inference goes is tuned to your content, so the resulting topic tree matches how your book is actually organised instead of a fixed default.
A generic conversion produces valid DITA with inferred structure, generic infotypes and generated IDs — a correct starting point that still looks like the source. A customer-specific conversion maps your named paragraph styles to the right semantic elements, tunes topic depth to your content, maps editorial conditions to your ditaval profiling scheme, applies your IDs and folder conventions, and validates against your DTD and specialization so the output drops straight into your CCMS and is authorable on arrival.
No. Content conservation is a zero-tolerance rule across every DocentraX conversion: structure may degrade gracefully where it cannot be confidently inferred, but visible text is never dropped. The completeness check verifies references, links and image references before anything is delivered.
It accepts InDesign HTML exports as .htm, .html or .xhtml files, or a .zip of the whole export including its images, and returns .dita topics with a map in the structure your platform expects.
We'll convert them to DITA free of charge — through the real pipeline, not a demo — and review the output with you. Then we'll discuss pricing one-to-one.
Request your free sample conversion