Choosing a DITA conversion vendor is largely an exercise in asking the questions a demo is designed to avoid. Every credible supplier can show you clean DITA from clean input; the differences appear in how they handle conditions, reuse, validation, orphaned topics, and the corrections your reviewers raise once they are deep enough into the corpus to find them. Here is the question set, the red flags, and a bake-off design that uses your content instead of theirs.
What you are actually buying from a DITA conversion vendor
A conversion contract looks like a file-format problem and behaves like a systems-integration problem. The deliverable is not "DITA" — it is content your authors can edit, your CCMS will accept, your publishing pipeline will render, and your reviewers will recognise as their own. Any competent supplier can produce well-formed XML. The distance between candidates shows up entirely in the parts nobody demos.
This is a buyer's guide, not a pitch. Ask every candidate the same questions, including us, and compare the answers side by side. If you are still scoping the project itself, the DITA migration services overview covers what a full migration includes, and the companion guide on DITA conversion cost covers what moves the number.
Ten questions to ask every DITA conversion vendor
- Do you convert my source natively, or convert it to something else first? A supplier who round-trips your Flare project through generic HTML has thrown away the variables, the snippets and the conditions before conversion even starts. Ask which authoring tools they open as whole projects rather than as loose pages — Flare, RoboHelp, FrameMaker, Sphinx, Word — and ask what happens to the parts of those projects that only the authoring tool understands today. For exports that genuinely are loose pages, such as InDesign or Drupal output, ask instead how reading order is decided — and whether that inference is flagged for your review or passed off as design. Vague answers here predict vague output.
- Where does reading order come from? Good answer: from the navigation your readers already use — the table of contents your Flare or RoboHelp project publishes, the contents pane of your generated WebHelp, the navigation tree of your documentation site. The hierarchy readers navigate today should be the hierarchy you get in DITA. Weaker answer: from file names or folder order, which is honest enough for sources that genuinely have no navigation, but it should be stated as a limitation rather than presented as design.
- Do you validate against my DTD or specialization, or against generic DITA? "Valid DITA" and "valid against your DITA" are different claims. Ask for a validation report generated against your own schema, covering well-formedness, DTD conformance, broken links and cross-references, conref and keyref resolution, image references, duplicate IDs and keys, and circular map chains — the checks a repository-scale DITA completeness check performs. Then ask one question most suppliers cannot answer: how do you prove the table grids? A CALS table can validate against the DTD and still be arithmetically impossible — a span overrunning the declared columns, two cells claiming the same position, a morerows value running off the end of its section. Grammar validation cannot catch any of that; ask for evidence their checks do.
- What happens to conditions, variables and snippets? The single most revealing question. Flattening conditional text into plain paragraphs produces output that validates perfectly and destroys your single-sourcing. Ask specifically: does my conditional text arrive as real ditaval profiling I can still publish from? Are my variables resolved to real values, or re-expressed as keys I can manage centrally? And are snippets nested inside other snippets handled, or only the top-level ones — because nested reuse is exactly where cheaper conversions quietly drop content.
- What is the reuse strategy on the far side? Migration is the cheapest moment you will ever have to create reuse, because duplicate content can be recognised and consolidated in bulk while everything is already open. Ask whether identical topics, images and repeated blocks are collapsed to a single master with every reference rewritten to point at it, or whether your duplication is simply carried into DITA unchanged. This is what Content Convergence addresses.
- Is the output repeatable? Run the same input twice; you should get byte-identical output. Non-determinism means you cannot re-run after a mapping change without re-reviewing everything from the start, which quietly makes iteration unaffordable.
- What happens to content that is not in the table of contents? Every legacy corpus has orphans — topics reachable by link but absent from navigation. The right answer is that they are converted and flagged as orphans for your decision. "They are excluded" means silent content loss; "we did not find any" usually means nobody looked.
- Who fixes it when page 38,412 is wrong, and what does that fix cost? Ask how a defect found in review is corrected: by hand-editing that one file, or by amending the mapping and re-running the corpus. The second fixes every instance of the same problem, including the ones your reviewers have not reached yet. Then ask whether re-runs are billable.
- Is the migration done when files land, or when content is accepted in the CCMS? Define acceptance in the contract. "Delivered" should mean imported, validated, opening correctly in your editor and publishing through your pipeline — not a zip file on a server.
- What happens on the next project? Ask whether the mappings and decisions you approve are kept as your configuration for future work, or discarded when the project closes. Ask too whether they can move content back out — to Markdown, DocBook or slides — because a supplier who handles DITA transformation in both directions is not betting your content on one destination.
Red flags in a DITA conversion services comparison
- Demo-only samples. The sample was produced from their content, or from three of your cleanest pages. Insist on your worst material.
- "Looks like DITA" output. Topics that are all generic <topic> with no infotyping, headings faked with bold paragraphs, admonitions left as styled text, tables that lost their spans. It parses; it does not mean anything.
- Per-iteration billing for corrections. Any model where your reviewers' diligence increases the invoice will suppress the review depth the project needs.
- No validation report. If they cannot hand you a machine-readable issue list with the file and location of every issue, they are asking you to accept quality on assurance alone.
- No orphan or exception handling. Content that does not fit the mapping must surface somewhere — a flagged topic, a cleanup list, a warning log — and never be silently dropped.
- Bespoke code written per project. Not disqualifying, but ask who maintains it, and what happens when the developer who wrote yours leaves. Mapping decisions you can read and adjust survive staff turnover far better than one-off scripts.
- Reluctance to quote against a real analysis. A firm price with no inspection of your corpus is either padded or a scope dispute waiting to happen.
How to run a fair bake-off with your own messy content
A pilot decides more than any proposal. Design it so it cannot be gamed.
- Pick the sample yourself, and pick it badly. Choose the chapter with the dense specification tables, the topic tangled in conditions, the file with snippets inside snippets, the scanned appendix. Add one clean chapter as a control.
- Give every candidate identical inputs. Same files, same DTD or specialization, same naming and folder conventions, same profiling scheme, same target — topic-per-file with a bookmap, or composite, but the same one for all.
- Write the acceptance criteria before you see any output. Otherwise you will grade on whichever quality the first sample happens to have.
- Validate everything yourself. Run your own validation against your own schema. Do not accept the supplier's report as the evidence for the supplier's work.
- Import into a sandbox CCMS. This is where folder layout, ID conventions, key collisions and asset references either work or do not.
- Ask an author to edit a converted topic. Five minutes in your own editor exposes generic infotypes, wrong note types and broken reuse faster than any report will.
- Then break it on purpose. Send one correction request — a style mapped wrongly, a note type changed — and see what comes back, how long it takes, whether the fix propagated across the whole corpus, and whether it was billed.
A scoring sheet you can reuse
| Criterion | Weak answer | Strong answer |
|---|
| Source handling | "We convert HTML" | Each authoring tool handled as the whole project it is, with reading order taken from the navigation your readers already use |
| Semantics | Generic topics, styled text | Infotyped topics, real notes, tasks from procedures, CALS tables with spans preserved |
| Conditions and variables | Flattened to text | Real ditaval profiling you can still publish from; variables resolved or keyed; nested snippets landed in place |
| Validation | "It's valid DITA" | Report against your DTD covering links, conref, keyref, image refs, duplicate IDs, circular maps — and table grids proved arithmetically sound, not merely valid |
| Repeatability | Manual touch-ups per file | Same input, same output; corrections made once and re-run |
| Content conservation | Unmatched content dropped | Nothing lost; structure may degrade gracefully, text never disappears; orphans flagged |
| Definition of done | Files delivered | Imported, validated and accepted in your CCMS |
| Second project | Start again | Approved mappings kept as your configuration |
One worked example: how we answer
For transparency, here are DocentraX's answers to the same ten questions, offered as a benchmark to compare against rather than as the only acceptable set. Each authoring tool is read as the project it is, the way the tool itself reads it, so the reading order and hierarchy your audience navigates today is the hierarchy that arrives in DITA. The mapping decisions — specialization, style semantics, conditions, keys, metadata, naming, folder layout — are held as configuration you approve rather than code rewritten for each job, so the same input always produces the same output. Conditions, variables and snippets survive as living constructs, including snippets nested inside other snippets, and topics that sit outside the table of contents but are still reachable by link are converted and flagged for your decision rather than dropped. Content conservation is a zero-tolerance rule: structure may degrade gracefully, text is never lost. Every job is validated against your own schema before delivery, a correction is made once and re-run across the whole corpus, and the decisions you approve carry into your next project instead of being made again. Where you later want the same content out again as Markdown, DocBook or slides, the same machinery runs in the other direction.
Judge that the way you should judge anyone's claims: by sending twenty-five pages of your worst content and validating the result yourself. What to send, and what to look for when it comes back, is set out in the DITA conversion overview.
Frequently asked questions
How do I choose a DITA migration partner?
Evaluate on the parts that do not appear in a demo. Confirm the vendor converts your source natively rather than round-tripping it through generic HTML, that they validate against your own DTD or specialization, that conditions, variables and snippets survive as constructs rather than flattened text, that the same input always produces the same output, and that orphaned content is flagged rather than dropped. Then test all of it on a pilot using your worst content, not theirs.
What questions should I ask a DITA conversion vendor?
Ask where the reading order comes from, whether your conditional text arrives as real ditaval profiling you can still publish from, whether variables are resolved or keyed, whether snippets nested inside other snippets are handled, whether the same input always produces the same output, what happens to topics missing from the table of contents, how a defect on page 38,412 gets fixed and whether that fix is billable, whether done means files delivered or content accepted in your CCMS, and what carries over to the next project.
What are the red flags when comparing DITA conversion services?
Samples produced from the vendor's content instead of yours; output that parses but carries no meaning, with generic topics and admonitions left as styled text; billing that charges per correction pass, which penalises thorough review; no machine-readable validation report against your schema; no handling for orphaned topics or exceptions; and a firm price quoted without any inspection of your corpus.
Should I run a pilot before committing to a DITA conversion company?
Yes, and design it so it cannot be gamed. Choose the sample yourself and choose difficult content, give every candidate identical inputs and targets, write acceptance criteria before seeing any output, validate the results against your own schema rather than accepting the vendor's report, import into a sandbox CCMS, and have an author edit a converted topic. Finally, request one correction and observe how it is handled and whether it is billed.
Is it cheaper to do DITA conversion in-house than to hire a vendor?
In-house works when the corpus is small, consistent and comes from a structured source, and when someone has time to learn the tooling. It stops working at scale, because the hard parts are not the conversion itself but maintaining the mapping as you learn, handling conditions and reuse, validating at repository scale and getting content accepted in the CCMS. A useful test is to convert one difficult chapter yourself first: what that takes, multiplied by your content families, is your real in-house estimate.
How do I compare DITA conversion vendors fairly?
Hold every variable constant except the vendor. Same source files, same DTD or specialization, same naming and folder conventions, same profiling scheme, same output target. Score against a fixed sheet covering source handling, semantic fidelity, condition and variable handling, validation evidence, repeatability, content conservation, definition of done and what persists into the next project. Grade the output in your own tools, not in the vendor's.
Related conversions
Send us 25 pages. The messier, the better.
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