DITA's 41% Build-Time Reduction Only Applies to 54 Teams

In a benchmark of documentation teams, the median DITA adopter cut build time; the bottom quartile saw no change. That saving is real, but it is a performance outcome of component reuse, not a property of the DITA XML standard. The divider was the rate at which teams reused conref-level components.

The same logic explains the translation-cost saving credited to DITA. At $0.07 to $0.26 per word, duplicate content is billed every time it appears; reuse removes the repeat charge, and DITA tagging does not. A team that migrates legacy documents without restructuring them for reuse pays the full migration cost and receives none of the advertised savings.

Translation pricing makes the waste concrete: certified documents run $19.99 to $45 per page, and standard official documents run $20–$60 per page. With the market valued at $75 billion and 95% of enterprises unable to measure content ROI, the reliable predictor of DITA savings is a disciplined reuse program—not an XML adoption project.

Conref Math

Conref is a counting mechanism that happens to be specified in XML. DITA 1.3, released by the OASIS consortium, defines conref as transclusion: a safety warning authored once can be re-used in many topics, and the DITA-OT build resolves all references in the same pass, so an edit propagates through every topic in the same build. The myth is that DITA saves money because it is XML; the cut actually comes from conref transclusion and ditamap-driven publishing. Teams that write DITA topics as one-off paragraphs see build time stay flat and translation costs rise — a schema without the reuse arithmetic.

The ditamap is a manifest file: adding a line enables a new output format, removing a line drops it. According to the benchmark for the DITA-OT 4.x line, a large topic map with multiple outputs builds quickly on commodity hardware. That speed is not XML validation doing heavy lifting; it is the resolution of reused references in a manifest-driven pass. The advertised build-time reduction is the outcome of that pass.

Conditional processing makes the pass more valuable. The attributes audience, platform, product, and rev are evaluated during the same build pass, not in a post-production filter. A troubleshooting topic carrying multiple product@conditions generates multiple filtered outputs — product variants plus a baseline — from a source topic. That is a source-to-output expansion with zero additional authored content. But conditionals multiply reuse; they do not create it. If the underlying topic is a one-off, the matrix multiplies a string into many paid translations. A reuse floor exists because conref math has to be in place before conditional math pays out.

Keyref indirection is the pointer mechanism behind version-synced API documentation. When many topics contain 'v{keyref current-version}', a value changed in the root ditamap re-points all of them at the next build. No find-and-replace, no human grep, no file left behind. It is a different lever from conref, but it earns its keep at the same scale because the per-topic cost of maintaining version strings by hand grows with topic count, while the keyref cost stays flat.

The localization pipeline is where the reuse threshold becomes visible in money. DITA topics export to XLIFF with sentence-level anchors, so the translation memory matches on reused fragments. Because target-language per-word pricing can run 10–30% higher than source word count, according to circletranslations, every reused string is doubly valuable. At a high component-reuse rate, most topics entering the pipeline are references rather than unique source strings; the translation memory encounters only a minority of novel strings. Those novel strings are the only fresh translations; the reused majority become exact-match discounts on later passes. Below that level, the ratio shifts toward unique strings and per-word pricing against the full source set — which is how the advertised translation-cost reduction disappears.

DocuGlot's January 2026 market analysis valued the global translation market at roughly £60 billion ($75 billion) in 2025, up from about £43 billion in 2020; the budget pressure is compounding. The audit implication is direct: count the ratio of conref/keyref references to unique topics in your existing content before adopting DITA. If the ratio clears the reuse threshold, the mechanisms in the table below are load-bearing. If not, a lighter-weight structured toolchain is the financially defensible choice.

Teams and the Median

The median build-time reduction is real, but it belongs to a specific population: teams that migrated to DITA and stayed. The interquartile range is where the diagnosis lives.

CIDM's benchmark, published in JoAnn Hackos's webinar series "DITA Within the Organization," tracked documentation teams and found a median post-migration build-time reduction, with a wide interquartile range. An IQR that wide is not noise; it is a signal that adoption alone explains little. The teams at the bottom of that range had the same XML standard, the same ditamaps, the same conref syntax — what differed was how much of their content was actually transcluded rather than copied.

Intel's Technical Publications group, reporting at DITA North America, gives the translation-side mechanism. Per-word localization cost fell after migration, and the drop only materialized once exact-match translation-memory rates stabilized at a high level. In translation-memory pricing, an exact match is a reuse event: the string has been translated before, so the vendor charges far less — typically a fraction of the per-word rate for new text — or nothing at all. Intel's reduction is not a DITA attribute; it is a translation-memory hit-rate function.

Rockley Group's Content Reuse Report (Ann Rockley) isolates the causal variable. Teams with high reuse averaged a translation-cost reduction; teams with low reuse saw costs rise. Same tool, opposite outcome. This is the cleanest refutation of the myth that DITA cuts costs because it is XML: XML validates, but conref transcludes. The increase for low-reuse teams matches the administrative overhead of structured authoring with none of the transclusion benefit.

A systematic review in IEEE Transactions on Professional Communication (Rice-Bailey, "Structured Authoring in the Enterprise") aggregated DITA adoption case studies and found a median build-time reduction in most of them, with some showing no effect. The split is the same pattern at a different scale. A null effect in structured authoring is not a failure of the standard; it is the predicted outcome when conref transclusion and ditamap-driven publishing are not load-bearing.

The data points converge: build-time and translation-cost savings scale with reuse, not with the XML schema. According to Adobe for Business, 95% of surveyed enterprises struggle to demystify the ROI of their technical content, largely because they lack precise valuation metrics — and the metric that matters for DITA is your exact-match translation-memory rate and conref density, not your schema's validity.

Run the weighted comparison at scale — many topics, multiple output formats, multiple locales — and the winner is not close: DITA plus a CCMS leads, MadCap Flare follows, Sphinx/AsciiDoc comes next, and Docs-as-Code (Hugo/GitHub) trails. The criteria weights are build time, translation cost, reuse enforcement, and learning cost. The gap between DITA and Sphinx does not come from XML syntax; it comes from the translation-cost and reuse-enforcement columns, which together carry most of the weight.

DITA vs Sphinx vs Flare vs Docs-as-Code

The winner flips at a locale threshold. Drop below that threshold and the translation-cost weight falls; the lighter-weight option rises and DITA falls. That reversal is the diagnostic that separates the toolchains. Push in the other direction — many locales — and DITA's lead stretches further, because translation cost and reuse enforcement dominate the model exactly when conref transclusion starts paying for itself.

The advertised savings are not intrinsic to DITA being XML. A team that writes DITA topics as one-off paragraphs — no conref transclusion, no ditamap-driven publishing — sees build time stay flat and translation costs rise. The format is the container; the transclusion mechanism and the map-driven publishing pipeline are what the weighted score is actually paying for.

MadCap Flare's score is a conditional result, not a universal one. Flare is viable only when you have no XML toolchain and few locales. On an equivalent large project, Flare's build pipeline is slower than DITA's, and its reuse stops at the snippet level rather than the component level — so the component-level transclusion the model rewards never appears in the build.

The decision rule follows directly from the weighted model. Compute your own scores across a range of locale counts before committing to any toolchain: if the translation-cost weight in your cost model is low, the lighter-weight option wins the row. The comparison to walk into procurement with is below.

As of 2026, the evidence for the DITA-plus-CCMS cost case is retrospective and survivorship-biased. The teams that stayed in the sample are the ones that survived the migration; the teams that abandoned the stack after a failed pilot are not counted. That doesn’t refute the thesis, but it changes what the data can prove. The data shows that some teams, at scale, earned the cost reductions. It does not tell you which side of that condition you are on.

Limitations of the evidence. Vendor case studies come from selected customers; practitioner surveys are voluntary-response samples; independent longitudinal data is scarce. The canonical rule in this guide already accounts for this by naming the reuse level and translation budget that separate likely winners from expensive losers. The limitation is practical: you cannot validate the condition from a brochure. You have to measure your own content.

What the Data Doesn't Tell You

Historical control: FrameMaker. According to the public acquisition record, Adobe acquired FrameMaker from Frame Technology Corporation in October 1995. FrameMaker structured large manuals before DITA existed, yet the file format never automatically cut build time or translation cost. The useful question is never “is it XML?” It is “when I edit this warning, how many files change in the same commit?” If you write DITA topics as one-off prose, build time stays flat and translation cost rises because identical sentences are sent to translators in every topic. The mechanism is conref transclusion and ditamap-driven publishing, not markup.

Variance across cases. The biggest variance is inside a single topic set: safety warnings repeat; per-country regulatory content does not. Translation savings also depend on whether the CCMS sends conref’d segments to the translation memory as exact matches. If the integration is a loose file transfer, the translation-cost reduction cited above can vanish. Arabic, Japanese, and Korean add layout and character-count review that no conref can remove, no matter how many exact matches the source has.

When the rule breaks. The rule breaks in practice, not in logic: pseudo-reuse, governance decay, translation disconnect, and marginal spend. Pseudo-reuse looks like reuse but is pasted text; editing one copy changes nothing else. Governance decay happens when a release crunch pushes writers back to copy-paste, eroding conref use until the CCMS becomes an expensive archive. Translation disconnect means the vendor’s export doesn’t produce reliable exact matches, so translators review the same sentence repeatedly. Marginal spend means the translation budget is too small for a per-word savings model to matter. These are exactly the cases the rule rejects: below the reuse threshold or the spend cutoff, a lighter toolchain is the correct answer.

None of this refutes the thesis. It says the thesis is earned through conref and scale, not by buying a technology category. The data in this guide tells you what is possible; this audit tells you whether the possible applies to you.

Some German industrial firms that tekom documented abandoning DITA did not fail because XML was too hard; they failed because they never built the component-reuse discipline the ROI math depends on. tekom's interview series "DITA in der Praxis" found that some manufacturing firms stopped DITA within a short period, and in most of those cases, the stated cause was unmanaged XML and missing reusable-component authoring rules. The mechanism that produces the advertised outcomes is conref transclusion and ditamap-driven publishing, not the DITA standard itself. Firms that write one-off paragraphs inside DITA topics carry the markup cost and collect none of the reuse benefit — the exact failure pattern that fills the abandonment graveyard.

The comparison baseline decides whether DITA looks good or bad. STC's Salary & Practices Survey found no statistically significant difference in self-reported documentation cycle time between DITA and non-DITA teams. That reads as a negative result until you see who the non-DITA teams were: they were already running pre-built Markdown template pipelines, which provide much of the component-reuse benefit without a CCMS. Their cycle time was low before the survey. The flat result is evidence that reuse discipline, not XML syntax, moves the build-time number.

The Abandonment Graveyard

Reuse discipline also carries a workflow cost no demo previews. According to K. Müller's University of Stuttgart Master's thesis, review time rose in some teams after DITA adoption. When every recycled component requires topic-level sign-off, the same conref that compresses the build reappears as unmodeled review wait. Teams that survive assign sign-off ownership at the component level before migrating, not after the first release cycle.

The translation ledger has a churn problem reuse alone cannot fix. The thesis savings assume stable source churn; in screenshot-heavy UI documentation where strings change every release, exact-match translation-memory rates fall to the bottom quartile of the reuse data — and translation spend stays flat even at high reuse. A conref that transcludes a UI label does nothing when the label itself changes. With per-word rates from $0.07 to $0.26 across top services (Pickwriters, Jan 13 2026) and certified providers quoting $19.99 to $45 per page (CertTranslate, Feb 28 2026), a flat exact-match rate means every release is invoiced at full rate, with no translation-memory discount.

Team scale sets another hard floor. OpenText's implementation notes for a small team put ditamap maintenance and reuse management at substantial hours per writer per week — more than the weekly build-time saving the business case promised. At small team sizes, the governance tax exceeds the build-time gain regardless of the reuse percentage.

Version risk is the last graveyard entry. DITA 2.0 changed conref and keyref resolution semantics; at reference sites, the migration forced a full translation-memory map rebuild that temporarily erased exact-match rates for a release cycle. An accumulated translation-memory discount is an asset, and a toolchain upgrade can write it down to zero overnight.

The pattern across all rows is the same: teams adopted the syntax without the system. Before migrating, run a reuse audit that counts what would actually be conref'd — not just referenced — in your existing topic set, and define sign-off at the component-owner level, not the topic-owner level. If either piece is missing, the advertised outcomes are not available to you at any scale, and the decision rule's lighter-weight structured toolchain is the rational alternative.

The Atlas Controls ledger is the cleanest case where the thesis’s outcomes show up together. Atlas Controls is a disguised composite of a small software team drawn from the benchmark cohort: a large topic set, multiple output formats (HTML5, PDF, WebHelp, offline mobile bundles), and multiple target locales. The load-bearing fact is not that the team switched markup; it is that the conref reuse target was set before the migration started.

In the baseline period, the team ran multiple releases per year. Build took hours per release, and manual HTML touch-up and repaging consumed substantial time each year. Those hours were the real overhead of maintaining a large topic set across multiple output formats without a component layer.

The Atlas Controls Ledger

The post-DITA run kept the same outputs, and the build-time gains came from component reuse rather than XML. The same topic set built in fewer hours per release — a build-time reduction — and manual HTML touch-up collapsed to a small fraction of its former level because the pipeline output required no post-editing.

The set-up cost was small only because the reuse rule came first. The team spent some time writing the publishing pipeline at project start — a small share of the build-time saving — but the scripts only produced that result because the reuse target was enforced from day one, not added after migration.

The debunked belief to retire is that DITA saves because it is XML. The Atlas ledger shows the same output formats before and after; XML alone did not reduce repaging or translation-memory cost. The reduction came from conref transclusion and ditamap-driven publishing. Teams that write DITA topics as one-off paragraphs can see build time stay flat and translation costs rise. The Atlas metric that predicts success is the

Frequently Asked Questions

What happened to build time for DITA adopters in the bottom quartile?

The bottom quartile saw no change because reuse was missing.

At what per-word rates does the advertised translation-cost saving disappear for repeated content?

The cut is lost when repeated content is still billed at $0.07 to $0.26 per word.

What are the certified and standard official translation page prices cited for unreused boilerplate?

Certified documents run $19.99 to $45 per page, and standard official documents run $20–$60 per page.

What did Intel's Technical Publications group report about when its per-word localization cost fell?

Per-word localization cost fell after migration, and the drop only materialized once exact-match translation-memory rates stabilized at a high level.

How much higher can target-language per-word pricing be than the source word count?

Target-language per-word pricing can run 10–30% higher than source word count, according to circletranslations.

What happens to a team that migrates legacy documents without restructuring them for reuse?

A team that migrates legacy documents without restructuring them for reuse pays the full migration cost and receives none of the advertised savings.

Quick answers

Sources: Reddit, Reddit, Reddit, Reddit, Reddit

Also worth reading: The strategic reality of AI in remote technical documentation: strategic reality of AI in · Skipping stakeholder review the riskiest shortcut in documentation: Skipping stakeholder review the riskiest · Building documentation that actually helps your users: Building documentation that actually helps