How long does a DITA migration take?

There is no honest generic answer to how long a DITA migration takes. There is an honest list of what moves the schedule: six factors, and the condition of the source matters more than raw page count. This guide sets out the six, where the elapsed time sits, and what shortens it. It quotes no figure in weeks or months, because a schedule has to be built on your real corpus instead of an average one.

The six factors that move a DITA migration schedule

1. How much of the corpus a machine can still read. The dividing question is whether the source still carries its structure in a form a machine can read, or whether that structure exists only in how the page looks. Tool projects, styled Word documents and structured HTML or Markdown convert predictably. A PDF has to be rebuilt into real document structure first, and a scanned page needs OCR and repair before that. Our guide to legacy content migration puts this factor first.
2. The number of distinct source types. Each tool takes its own conversion path. Record which tool really produced each file; the tool people name is often not the one the content came out of.
3. The styles and conditions genuinely in use. They set the true scope of the style-to-element map. Count the styles actually used, not the styles defined. Conditions, variables and reusable snippets add rulings of their own: what becomes profiling, what becomes keys, what is resolved to text.
4. Whether the target model exists. A specialization and a metadata model either exist already or must be designed, and design work sits on the schedule ahead of conversion. How quickly the style-to-element map and the metadata model are agreed decides when volume can start. Migrations rarely stall on conversion; they stall waiting for someone with the authority to say what a paragraph styled "Note — important" should become.
5. Review rounds and review capacity. How many rounds your organisation needs to reach sign-off, and who is free to do the reviewing. Inferred structure needs human eyes, so review capacity, not conversion throughput, is usually the real constraint.
6. Localisation. Migration disturbs translation memory, because segmentation changes when a run-on paragraph becomes numbered steps or a table cell. Localised content adds a memory re-alignment and a translation freeze across cutover to the plan.

Where the elapsed time sits

Most of the elapsed time sits in analysis and pilot review, where the decisions are made. Once the mapping is agreed, converting the full estate is a repeatable batch run, and refinements after that are re-runs rather than fresh rounds of hand work. The schedule of a rule-driven migration is therefore set by the tailoring agreed in the pilot and by the volume that then runs through it as a batch, not by manual per-page effort. How that project runs, stage by stage, is described under DITA migration services.

The DITA migration checklist shows the same thing from the planning side. Of its 14 steps, steps 1 to 8 are decisions that produce documents, and steps 9 to 14 are execution that produces content. If conversion at scale begins before step 8 is signed off, you are not migrating; you are manufacturing rework. That is why the pilot deserves your best reviewers.

"Files delivered" and "content accepted in the CCMS" are two different definitions of done, and confusing them is the single most reliable way to blow a schedule. What acceptance takes is covered in our guide to CCMS migration.

Why page count is a weak driver

Raw page count is a weaker driver than source condition: a large corpus of styled documents moves faster than a small pile of scans. Corpora that are large but uniform move faster than small ones assembled from many tools and eras. Volume still counts, but once the mapping is settled it counts as a machine job, not as a fresh manual project for every batch.

This is also why the two kinds of content should never be scheduled 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; see the second pile for why the hard one stalls whole projects.

What shortens a DITA migration

• Retire content before you convert it. The cheapest page in any migration is the one you delete.
• Hunt for originals. Before scoping any PDF, search for the source document. Every original you find moves a document from the expensive pile to the cheap one.
• Name the open decisions first. Specialization, CCMS, topic typing, metadata model, reuse strategy, style mapping, acceptance criteria: give each a named owner and a date before anyone touches content.
• Find the hard pile before the schedule is fixed. The checklist lists its late discovery among the ways migration plans go wrong.
• Start the predictable pile at once. Run volume on the content that converts predictably while the hard pile is still being assessed, so the hard pile gets scoped with real data.
• Pilot on your worst content, not your best. An easy pilot produces a plan that collapses the first time it meets hard content.
• Agree acceptance criteria before the pilot output arrives. Make them machine-checkable, and run validation as a gate at every iteration.
• Keep reviewers reviewing. Reviewers do not hand-edit output. A finding becomes a rule change and the corpus is re-run, so it fixes every instance at once. Timebox the rounds and expect more than one.

What to build the estimate on

Inventory by source condition before estimating anything at all. Count documents and pages for each condition, from tool project to scan. Add the styles, conditions, variables and snippets actually in use, and the localisation status. Many of the same facts drive the price, as set out in our guide to DITA conversion cost.

You can also see how your hardest pages convert before you plan around them: the free 25-page sample converts up to 25 pages of your own documents through the production pipeline.

Frequently asked questions

Is there a typical duration for a DITA migration?

There is no honest generic answer, but there is an honest list of what moves it: how much of the corpus is unstyled or scanned, the number of distinct source types, the styles and conditions genuinely in use, whether a specialization and metadata model already exist, the review rounds needed to reach sign-off, and whether the content is localised.

Does a larger corpus always take longer to migrate?

No. Raw page count is a weaker driver than source condition: a large corpus of styled documents moves faster than a small pile of scans.

Where does most of the time go in a DITA migration?

Into analysis and pilot review, where the decisions are made. Once the mapping is agreed, converting the full estate is a repeatable batch run.

What shortens a DITA migration?

Deciding what not to migrate is the single highest-leverage step, so retire obsolete content before conversion. Then look for the original source of every PDF, agree the style-to-element map and the metadata model once, and have reviewers amend rules rather than edit output.

Related guides

• The DITA migration checklist: 14 steps, in order
• DITA migration services: legacy documentation into your CCMS
• Legacy content migration: what converts cleanly, what needs rebuilding
• DITA conversion cost: what actually drives the price
• See the output on your own content: free 25-page sample