Drupal is a great way to publish a website and a poor way to own structured documentation — which is why Drupal to DITA conversion matters the moment your content has to live anywhere but that site. DocentraX runs the full path of conversion, migration and transformation: your export becomes clean, valid DITA, and the structure the site only ever assembled at render time is rebuilt as a real topic hierarchy — so your documentation becomes owned, reusable and single-sourced instead of borrowed from a platform.
Content trapped in a CMS is content you can only use one way — as that website. You cannot single-source it into a manual, reuse a section across products, or publish it to a channel Drupal does not drive. It is coupled to a theme, a database and a runtime; the words are the asset, the platform is the constraint. The day someone asks for the same content as a PDF, an in-product help panel and a partner deliverable, you discover you own a site rather than a content set.
Pulling documentation out of Drupal by hand means fighting site furniture, inconsistent templates and a menu that only ever existed while the page was being rendered. A repeatable conversion that understands what a CMS export is — and what it is missing — avoids that grind, which is why treating this as one of your DITA migration services beats page-by-page copy-paste that nobody can review or re-run.
A CMS publishes your content. It does not let you own it as content. DITA does.
We read the export as a documentation source rather than as a pile of web pages. Navigation bars, breadcrumbs, footers and template scaffolding are recognised as furniture and left behind; every published word is kept. Heading levels become a genuine topic hierarchy, tables become CALS tables with real rows and cells, and notes, cross-references and images arrive as proper DITA elements instead of styled markup pretending to be meaning. Drupal has changed its export format over the years, so we detect which generation produced yours and run the rule set built for it, rather than forcing one set of assumptions onto both. Structure inference is tunable rather than fixed, the invisible spacing characters a CMS scatters through published text — the ones that quietly break search and inflate translation — are cleaned up on the way through, and the mapping from your theme's presentation to DITA semantics is shared and repeatable, so a decision made once holds across the whole site. Text is never dropped: where the source genuinely cannot be typed with confidence, structure degrades gracefully and the content still arrives.
Every Drupal to DITA migration runs the same five-stage lifecycle, and you see the output of each one.
We inventory every page, image and style the export contains, and establish the order your content should be read in. A Drupal site builds its menu itself at request time, so there is no menu inside the export to inherit — the shape of the export and your heading levels give us the reading order instead, and you confirm that order before anything is built on top of it.
Theme output becomes documentation semantics: a topic hierarchy from your headings, CALS tables from your tables, and real note, cross-reference and image elements — with the site chrome stripped away rather than carried along as noise, and your theme's procedure styling mapped to real tasks in a customer-specific run.
Your metadata, keys, IDs and naming conventions are applied, and you can optionally run Knowledge Fabric to write keywords and index terms into topic prologs, so the content arrives findable rather than merely valid.
The DITA completeness check runs against your own DTD — your specialization included — before delivery: validity, resolved links, conref and keyref targets, image references, duplicate ids and keys, circular map chains, across the whole repository rather than a sample.
One clean composite DITA document per title as the direct output — then, through the splitting step, individual typed topics with a bookmap and key map in exactly the shape your platform expects, so the load into your CCMS is an import rather than a project.
A generic run gives you valid DITA with inferred structure, generic topic types and generated IDs — correct, but shaped by the source. A customer-specific conversion aligns it to your model. For a Drupal source that means, concretely:
Because this tailoring is expressed as configuration rather than bespoke work repeated per batch, an amendment is a re-run across the whole corpus instead of a rewrite — one ruling fixes every page it touches. Without it, your team spends weeks turning web markup into documentation semantics by hand, one topic at a time, with no way to prove the job was done consistently.
| Your concern | How we answer it |
|---|---|
| Our navigation was assembled by the site, so the export has none. | Reading order is rebuilt from the shape of the export and your heading levels, and you sign it off before conversion proceeds. |
| The export is full of theme furniture and templates. | Navigation, breadcrumbs and footers are left behind; the published content is kept and rebuilt as real DITA elements. |
| Different content types were rendered by different templates. | We recognise which generation of Drupal produced your export and apply the rule set built for that format; each template's way of signalling meaning then maps to the matching semantic element in a customer-specific run. |
| We cannot lose any published content. | Content conservation is zero-tolerance: structure may degrade gracefully, published text is never dropped. |
DITA gives you single-sourcing, conref and keyref reuse, conditional publishing and multi-channel output — once content is migrated cleanly. Web CMS exports are a genuinely tricky source, because the structure was never in the pages: it lived in the database and the theme. Teams usually copy-paste, scrape with a throwaway script, or hand the problem to a services firm and hope. Our advantage is that we know exactly what a CMS export is missing and rebuild it deliberately — sensible reading order where the source carries no table of contents, a topic hierarchy inferred from your headings and confirmed with you, and repository-scale validation — all inside one DITA conversion pipeline you can re-run as your rules improve.
If your content did not come from Drupal, the same family covers it: HTML to DITA conversion handles web content from any other source, and Sphinx to DITA conversion handles developer documentation.
Content freed from Drupal becomes owned, structured DITA: single-sourced, reused through conref and keyref, conditionally published for different audiences, and delivered to any channel — including back to the web — from one governed source. You publish where you choose, on your own schedule, instead of being tied to a theme, a template and a runtime that were only ever meant to render one site.
We treat the export as a documentation source rather than a set of web pages. Site furniture — navigation, breadcrumbs, footers, template scaffolding — is left behind, your heading levels are rebuilt into a real topic hierarchy, and tables become CALS tables while notes, cross-references and images become proper DITA elements; a customer-specific run maps the styling your theme used for procedures to real DITA tasks. The result is validated against your own schema, across the whole repository, before it is delivered.
Yes, and it is the normal case: a Drupal site assembles its menu itself when a page is requested, so there is no menu inside the export to inherit. Reading order is rebuilt from the shape of the export and topic nesting is inferred from your heading levels, with the aggressiveness of that inference adjustable to your content, and you confirm the resulting topic tree before anything is built on top of it.
An exported Drupal site as HTML files, or the whole export delivered as a single zip — we recognise which generation of Drupal produced it and apply the matching rule set. The direct output is one clean composite DITA document per title; the splitting step then produces topic-per-file with a bookmap and key map in the layout your platform expects, so it loads into your CCMS rather than needing to be reorganised first.
A generic conversion produces valid DITA with inferred structure and generated IDs. A customer-specific conversion maps the patterns your theme used to signal meaning onto the right semantic elements, reshapes the topic hierarchy to the grouping you actually want, maps content variants to your ditaval profiling scheme, applies your IDs, filenames and folders, and validates against your DTD and your specialization.
Yes. Content conservation is a zero-tolerance rule: site furniture and templates are stripped, but published text is never dropped. Where structure cannot be inferred with confidence it degrades gracefully rather than discarding content, and the completeness check verifies every link, reference and image across the repository before delivery.
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