Every legacy content migration has two piles. The first is content whose structure a machine can still read — help projects, Word documents, HTML, Markdown, published FrameMaker — and it converts predictably, the same way every time. The second is the pile that stalls the project: scanned manuals, unstyled PDFs, documents whose only remaining structure is visual. This guide is about scoping those two piles honestly, getting the second one to the same starting line as the first, and sequencing the work so the easy majority never waits on the hard minority.
Migration projects rarely stall on the content people demo. They stall on the pile at the back of the archive: a shelf of PDFs produced by a tool nobody still licenses, manuals that exist only as scans, documents where every heading is bold 14-point text rather than a heading style. Nobody can scope that pile, so nobody wants to own it, so the estimate for the whole migration inherits its uncertainty — and a project that could already be delivering is still in planning.
The way out is not a better estimate for the hard pile. It is refusing to scope the two piles as one thing. Content with machine-readable structure and content without it have different conversion economics, different risk, different review effort and different schedules. Treat them as one work package and the cheap work inherits the expensive work's timetable.
The dividing question is simple: does the source still carry its structure in a form a machine can read, or does that structure exist only in how the page looks? Everything else follows from the answer.
| Source condition | What is recoverable | How it converts |
|---|---|---|
| Tool project files (help authoring, published output with its own navigation) | Reading order, topic hierarchy, variables, conditions, links, assets | Predictably, guided by the source's own table of contents |
| Styled Word documents | Heading hierarchy, list numbering, tables, footnotes, images | Predictably, with a style map to your element rules |
| Structured HTML or Markdown | Heading levels, tables, code, admonitions, page metadata | Predictably, with hierarchy taken from heading depth |
| Unstyled documents (bold text used as headings) | Text and reading order; structure only by inference | Predictably, but the inference needs review and a style map |
| Digital-native PDF | Headings, lists, tables and images can be rebuilt as real document structures | PDF rebuilt into a Word document first, then the ordinary Word path |
| Scanned PDF or image-only manual | Nothing until OCR runs; then text with recognition errors | OCR first, then repair, then the ordinary path |
Two practical rules fall out of that table. First, if the original Word document still exists anywhere, use it — converting a PDF that was printed from a document you still own is paying twice for structure you already have. Second, everything eventually converges on the same predictable conversion; the hard pile simply needs more work to reach the entrance.
This is the majority of most corpora, and it should be moving while the hard pile is still being inventoried. We identify what each source really is by looking inside it rather than trusting its file extension, so a document renamed, re-saved or exported years ago is still handled as what it actually is. Your existing navigation defines the reading order, so the structure your readers know survives — and real semantics come back with it: headings become a topic hierarchy, numbered procedures become tasks, tables become CALS, and notes, admonitions, footnotes, cross-references and images all carry across.
Tool-specific sources — Flare, RoboHelp, FrameMaker, InDesign, Drupal, Sphinx — are each read the way their own authoring tool reads them, and are covered from the DITA conversion pillar. The point for planning is that this pile is predictable: the effort is in agreeing the style-to-element map and the metadata model once, then running volume.
The second pile is where honesty matters most, because it is where vendors are most tempted to promise magic. Here is the actual shape of the work.
For a digital-native PDF the file still contains real text, and headings, lists, tables and images can be rebuilt into real document structures — see PDF to DITA conversion for how that rebuild feeds the same Word-to-DITA path as pile one. For a scanned manual there is no text at all until OCR runs, and OCR output is never clean: words are cut in half at line ends, figure pages scatter their labels away from the artwork, tables lose their grid.
That is where recognition earns its place — and where it should be tightly bounded. Our approach separates three things that are usually conflated:
The output of all of that is an ordinary structured document, which then goes through exactly the same conversion, the same style map, the same validation and the same delivery as pile one. Nothing about the hard pile changes the target; it only changes what it costs to reach the starting line.
Converting unstructured content to structured content involves judgment calls, and judgment calls can go wrong. There is exactly one that must never go wrong: text is never dropped. Structure may degrade gracefully — a construct nobody can classify becomes a plain section rather than a specialized element, and a file too damaged to read cleanly is preserved as a topic flagged for cleanup rather than failing the job — but the words survive.
This is worth writing into your acceptance criteria explicitly, because it is the difference between a migration you can audit and one you have to trust. A degraded structure is visible, findable and fixable later by an author. Silently missing content is discovered by a customer, in a regulated field, at the worst possible moment. Ask any migration vendor what happens to content their tool cannot classify, and treat "it gets skipped" as a disqualifying answer.
Steps 5 and 6 running concurrently is the whole trick. The easy majority is in production and being reviewed while the difficult minority is still being assessed, which means the project shows visible progress early and the hard pile gets scoped with real data instead of anxiety.
Legacy migration is not primarily a technology problem; the conversion itself is the solved part. It is a scoping and sequencing problem, and it responds to the same discipline as any other large delivery: inventory honestly, separate the predictable work from the uncertain work, start the predictable work now, and buy information about the uncertain work before you buy a plan for it. For the full engagement model, see our DITA migration services, and for moving content between structured formats once it is in, DITA transformation.
Legacy content migration is the move of existing documentation out of formats that no longer serve the team — old help projects, desktop publishing files, Word documents, PDFs and scanned manuals — into a structured, single-sourced form such as DITA. The defining characteristic is that the sources vary wildly in how much machine-readable structure they still carry, which is why scoping matters more than tooling: content whose structure survives converts predictably, and content whose structure exists only visually has to be rebuilt first.
It depends on whether the PDF is digital-native or scanned. A digital-native PDF still contains real text, and its headings, lists, tables and images can be rebuilt into real document structures that then feed the standard conversion path. A scanned PDF has no text at all until OCR runs, and OCR output needs repair before it is usable. In both cases, look for the original source document first — if the Word file still exists anywhere, converting that is cheaper and more accurate than rebuilding from print output.
By inferring structure from the signals that remain and then validating the result. Heading levels, or the visual formatting that stood in for headings, drive the topic hierarchy; numbered procedures become tasks; tables, notes, footnotes, cross-references and images map to their structured equivalents. Where an authoring style carried meaning, your style map turns it into the right semantic element rather than a generic one. Inference always needs human review, so review capacity, not conversion throughput, is usually the real constraint.
Four things, in roughly this order: the proportion of the corpus that still carries machine-readable structure, how much content is retired rather than converted, how quickly the style-to-element map and metadata model are agreed, and the review capacity available for inferred structure. Notably, raw page count is a weaker driver than source condition — a large corpus of styled documents moves faster than a small pile of scans. Inventory by source condition before estimating anything at all.
Retire before, deduplicate after. Deciding what not to migrate is the single highest-leverage step and can only be done up front, while someone still has the authority to declare content obsolete. Deduplication is better done after conversion, when the whole corpus is in one structured form and duplicate topics, images and repeated sections can be collapsed to single masters with every reference rewritten automatically — work that is impractical while the content is still spread across incompatible legacy formats.
It degrades gracefully rather than disappearing. Content conservation is a zero-tolerance rule: a construct that cannot be classified becomes a plain structural element instead of a specialized one, and a file too damaged to read cleanly is preserved as a topic flagged for required cleanup rather than failing the job. Structure may be reduced, text is never dropped. That distinction matters because a degraded structure is visible and fixable by an author later, while silently missing content is discovered by a customer.
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