FrameMaker to DITA conversion turns the WebHelp your FrameMaker books were published as — the bundle your readers actually use — into clean, valid DITA with your book and chapter hierarchy intact. Whether you scope it as a FrameMaker to DITA migration or a full FrameMaker to DITA transformation, DocentraX reads the WebHelp's own navigation, so the structure your audience knows survives the move and no text is dropped along the way.
Your FrameMaker books were published as WebHelp, and that output is now the most complete, most current version of content you cannot easily move anywhere else. The unstructured FrameMaker source may be inconsistent, out of date, or simply lost; the WebHelp is real, but it is a publishing artifact, not a reusable content source. A FrameMaker to DITA conversion turns that published WebHelp into clean, valid DITA — with the book and chapter hierarchy your readers navigate preserved exactly.
Content that exists only as a published deliverable is content you cannot evolve. You cannot reuse a chapter across two books, you cannot publish it to a new channel, and you cannot feed it to a CCMS — because a WebHelp bundle is output, not source. Every year it stays that way, the gap widens between what your customers read and what your team can actually maintain.
Reverse-engineering that output by hand is worse than migrating clean source: the structure is implied rather than stated, and a manual effort almost always loses the book and chapter organisation that gives the content its shape in the first place. A deterministic FrameMaker to DITA migration that reads the WebHelp's own navigation avoids all of that, and plugs into the same DITA conversion pipeline as every other source you own.
A WebHelp bundle is the last thing you published — not the first thing you can build on. DITA changes which one you have.
We read your published WebHelp the way a reader does: starting from the navigation pane. The book and chapter hierarchy your audience clicks through is the hierarchy that lands in DITA, reconstructed rather than guessed at from file names — so the chapter that sits third under Installation today is still third under Installation when it arrives as a bookmap.
From there the transform rebuilds real DITA semantics rather than wrapping pages in a topic shell:
Content conservation is enforced end to end: where structure genuinely cannot be determined it degrades gracefully, but the text itself is never dropped.
A generic run gives you valid DITA with inferred structure, generic infotypes and generated IDs — correct, and a fair starting point, but not yet aligned to your standard.
A customer-specific FrameMaker to DITA conversion aims the whole thing at your CCMS instead. Concretely:
Skip the tailoring and someone on your team re-maps elements, rebuilds the book structure and reconciles metadata by hand, one topic at a time. Take it, and the DITA is production-ready on arrival — and because the mapping is configuration you approve rather than code written fresh for every job, the decisions you make on the first book carry into the next one instead of being made all over again.
DITA's payoff — single-sourcing, conref and keyref reuse, conditional publishing and multi-channel output through DITA-OT — is only unlocked once legacy content is migrated in cleanly, and that migration is the classic barrier. The usual routes are manual services, one-off scripts, or desktop tools that crawl the published pages and ignore the book they came from. Recovering published WebHelp is especially unforgiving, because the structure lives in navigation that was generated for browsers rather than for people.
A DocentraX FrameMaker to DITA transformation reads exactly that navigation, so the book hierarchy survives instead of being reconstructed by guesswork from folder names. It is one of a wider set of DITA migration services that converge every legacy source on a single standard.
| Your concern | How we answer it |
|---|---|
| "We only have the published WebHelp, not clean source." | We convert the published WebHelp itself and rebuild real DITA from it, so you do not need the original FrameMaker files to move. |
| "The book and chapter order must be exact." | Reading order comes from the WebHelp's own navigation, so the hierarchy your readers use is reconstructed, not guessed. |
| "We need bookmaps that match our conventions." | A customer-specific mapping aligns chapters to your bookmap conventions and validates against your DTD. |
| "How do we confirm links and images survived?" | The completeness check verifies links, conref, keyref and image references against your schema before delivery. |
Your FrameMaker books stop being a frozen WebHelp bundle and become living DITA: single-sourced, reused across books with conref and keyref, conditionally published with ditaval, and delivered to any DITA-OT channel you choose. If your estate spans more than one legacy tool, the same pipeline covers Structured FrameMaker to DITA and MadCap Flare to DITA conversion, so everything lands in one consistent standard instead of several near-misses. Output becomes source again.
This page is about published WebHelp — the case where the output is the most reliable thing you have. If your books live in Structured FrameMaker and can be saved as HTML, that is a different and cleaner route: see Structured FrameMaker to DITA conversion. And if you hold unstructured .fm or .book files, you are not stuck either: a publish run in FrameMaker produces exactly the WebHelp bundle this conversion reads, so the output you already know how to generate becomes your on-ramp to DITA.
DocentraX converts the published WebHelp itself, taking the reading order from its own navigation and rebuilding the book and chapter hierarchy as DITA topics and maps. Notes, tables, cross-references and images become real DITA elements rather than formatted text, and the result is validated against your schema before delivery.
Yes. That is the normal case, and it is exactly what this conversion is built for. We work from the published WebHelp as it stands, so you do not need clean unstructured FrameMaker source, and the output your readers have been using becomes reusable DITA source your team can maintain.
Yes. Reading order comes from the WebHelp's own navigation — the same contents pane your readers click through — so the book and chapter hierarchy is reconstructed exactly rather than inferred from file names or folder order.
A generic conversion produces valid DITA with inferred structure and generated IDs. A customer-specific conversion carries the meaning of your FrameMaker styles into the right DITA elements, aligns chapters to your bookmap conventions, and validates against your own DTD. One thing it will not promise: recovering conditional text from published WebHelp. The conditions were applied when the help was generated and leave no trace in the pages, so we re-establish profiling with you in DITA deliberately instead of pretending to recover it.
The publish folder exactly as it was generated, delivered as a single archive — including the publisher's own project and navigation files alongside the topic pages, because those are how the bundle is recognised as WebHelp; a bare set of HTML pages is not enough. Add your DTD or specialization and any naming and folder conventions you want followed, and you get DITA topics and bookmaps back, with images collected and every reference intact.
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