Structured FrameMaker to DITA conversion carries your element-based Frame authoring into the open standard, turning the HTML export into clean, valid DITA with chapter reading order preserved. Whether you frame it as a Structured FrameMaker to DITA migration or a full transformation, DocentraX reads that export as the publication it was — so nothing shuffles, and no text is dropped.
Structured FrameMaker already gave you element-based authoring — you were most of the way to structured content. But an EDD-driven Frame model is not DITA, and when you export it as HTML you get a set of chapter pages that still are not a reusable content source. A Structured FrameMaker to DITA conversion turns that exported HTML into clean, valid DITA with chapter reading order preserved, so the structure you already invested in carries forward to the open standard.
Structured FrameMaker is a capable but closed ecosystem. Your content model lives in EDDs and templates that only Frame understands; reuse and conditional publishing follow Frame's rules rather than the industry's. Moving to DITA makes your structure portable — governed by an OASIS open standard, publishable to every channel you deliver, and reusable in any modern CCMS, whether that is Heretto, Paligo, IXIASOFT or Tridion Docs.
The temptation is to treat this as a quick manual tidy-up, precisely because the content is already structured. It is not: the HTML export flattens the model, and a hand pass loses chapter order and maps the same element two different ways in two different chapters. A deterministic Structured FrameMaker to DITA migration that reads the export as a book rather than as a folder of files protects the investment you already made, and runs through the same DITA conversion pipeline as every other source.
You already did the hard part — authoring structured. DITA is where that structure stops being Frame's and starts being yours.
We read your export the way a reader opens it. The contents page you published is what defines the order, so chapter one is chapter one and appendix C lands after appendix B — not wherever an alphabetical file listing happens to drop them. That single decision is what separates a conversion you can ship from one your writers have to re-sequence chapter by chapter before anyone can even review it.
From there the transform rebuilds real DITA semantics rather than wrapping the export in DITA clothing:
Text is never dropped. Where the source genuinely cannot tell us what something was, structure degrades gracefully and the content survives — never the other way round.
A generic run gives you valid DITA with inferred structure, generic topic types and generated IDs — a correct start, and enough to prove every word made the journey.
A customer-specific Structured FrameMaker to DITA conversion aligns that output to your standard. Concretely:
Without that tailoring, the team reconciles element mapping by hand after delivery, which is the most expensive place to do it. With it, the DITA drops into your CCMS ready to use — and because the mapping is configuration we hold and reuse rather than a bespoke build each time, the tenth book behaves exactly like the first.
DITA gives you single-sourcing, conref and keyref reuse, conditional publishing and multi-channel output — once content is migrated cleanly. For Structured FrameMaker the common routes are manual re-authoring, a one-off script, or a desktop tool, and all three tend to lose the one thing an HTML export makes hardest to recover: the order the book was in. A DocentraX Structured FrameMaker to DITA transformation reads the export as the publication it was — identified by the contents page the export carries — and infers topic structure from your headings rather than from filenames. It sits alongside the rest of our DITA migration services, so a mixed FrameMaker estate — structured and unstructured, book and help — converges on one standard.
| Your concern | How we answer it |
|---|---|
| "We already author structured — is this just a relabel?" | No: the HTML export flattens your model, so we rebuild real DITA topics, tasks and CALS tables from it rather than renaming whatever the export happens to contain. |
| "Chapter order must not shuffle." | Reading order comes from the contents page of your own export, not from a file listing, so chapters and appendices stay in the sequence your readers know. |
| "We need our specialization, not generic DITA." | A customer-specific mapping takes your Frame elements and paragraph styles onto your specialization, and the output validates against your DTD. |
| "How do we verify the result?" | The completeness check audits links, conref, keyref and image references against your schema before anything is delivered. |
Your structured authoring investment carries forward into an open standard: single-sourced, reused with conref and keyref, conditionally published, and delivered to every channel your audience uses. If you also publish those books as online help, the same pipeline handles FrameMaker WebHelp to DITA conversion, and it covers RoboHelp to DITA conversion too — so every Frame and help source in the estate lands in one consistent DITA. The model becomes yours, not the tool's.
DocentraX reads your HTML export as a publication rather than a folder of files: the contents page you published defines chapter order, and headings, procedures, tables, notes and images are rebuilt as real DITA topics, tasks, CALS tables and elements. The output is validated against your own schema before delivery.
No. The HTML export flattens the EDD-driven Frame model, so DocentraX rebuilds real DITA topics, tasks and CALS tables from it rather than simply renaming elements. That is what protects the chapter order and the structure you already invested in.
Yes. Reading order comes from the export's own contents page rather than from how the files happen to be named or listed, so chapters and appendices land in the correct sequence. Text is never dropped, and structure only degrades gracefully where the source genuinely cannot tell us what something was.
A generic run gives valid DITA with inferred structure and generated IDs. A customer-specific run maps your Frame elements and paragraph styles onto your specialization, follows your ID and folder conventions, and validates against your DTD. Conditional text is the honest exception: an HTML export is a single build with the conditions already applied, so we re-establish profiling with you in DITA deliberately rather than pretending to recover it from the export.
The complete HTML export as FrameMaker produced it — the whole folder, or a zip of it, with its images and, critically, the contents page that lists your chapters in order. That page is how the export is recognised and where chapter order comes from, so an export delivered without it will not be identified; if yours lacks one, tell us and we agree the reading order another way before the sample runs. Add your DTD or specialization and any existing style mapping, and you get DITA topics and a map or bookmap back.
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