Field Guide
FrameMaker to DITA (or S1000D): Converting the Desktop Era
The Estate
Better Than Word, Messier Than SGML
On the conversion-difficulty spectrum, FrameMaker sits in the instructive middle. Validated SGML converts on rails; Word estates carry twenty years of formatting anarchy; Frame libraries carry discipline without enforcement. Structured Frame (authored against an EDD) converts nearly as predictably as SGML. Unstructured Frame, the wide middle, runs on paragraph tags that carry real signal when the template held: automation gets far, and the traps are at least characteristic, meaning hidden in overrides, anchored frames and text insets, hand-formatted tables, conditional text used creatively. Frame is the template-as-standard era at its best behaved, and its best behaved is still not a content model.
Which FrameMaker
Structured or Unstructured Decides Everything
Before anyone scopes a conversion, settle one question, because the answer changes the project by an order of magnitude: is the library structured or unstructured FrameMaker?
Unstructured FrameMaker is the classic desktop publishing product. Content is held together by paragraph and character formats, and whatever meaning exists lives in a convention: a paragraph tagged Head2 is a second-level heading because the template says so and the authors complied. Nothing enforces it. Extracting structure from that estate means inferring intent from formatting, and the quality of the inference is capped by how disciplined the authors were.
Structured FrameMaker is a different animal. It runs against an EDD and a document type, so the content is genuinely element-based and already validated against a grammar. Adobe also ships a DITA capability on top of it, which means some libraries are already authoring DITA and simply using FrameMaker as the editor. If that is your situation, you may not have a conversion project at all, you may have an export and a tooling decision.
The practical artifact in either case is MIF, the Maker Interchange Format: FrameMaker's documented text representation, and the usual input to a conversion pipeline because it can be parsed without driving the application. Binary .fm files are the thing you hold; MIF is the thing a transform reads. A conversion that starts by batch-saving the estate to MIF has begun sensibly. One that starts by opening files one at a time has not.
So the estimate question is not how many pages you have. It is which of these three situations you are in, because an unstructured library with an undisciplined template, a well-governed unstructured library, and a structured library already on an EDD are three genuinely different projects wearing the same name.
The Method
Audit the Template, Sample the Worst
The playbook is our standard one with a Frame-specific opening move: a template-consistency audit before anything else, because tag discipline is the whole ballgame. The same book count converts at wildly different cost depending on whether “Step” always meant step. Then the representative sample(oldest books, worst tables, inset-heavy chapters) through the real pipeline, yielding the automation rate, the exception catalog, and per-book effort. The cost drivers behave exactly as they do everywhere else; Frame just concentrates them in known places.
Target selection follows the standard logic: contracts choose S1000D; product-family reuse argues DITA (the most common Frame destination); and the convert-or-ingest split still applies. The settled tail of a Frame library can be published as-is through a delivery platform while the living families convert. The consistent good news: teams that chose FrameMaker two decades ago were choosing discipline. That choice is still paying dividends; a conversion project is where it cashes out.
FAQ
Questions We Hear
What is the difference between structured and unstructured FrameMaker?
Unstructured FrameMaker is the classic desktop publishing product, where content is held together by paragraph and character formats and any meaning lives in convention rather than enforcement. Structured FrameMaker runs against an EDD and a document type, so content is genuinely element-based and validated against a grammar. Adobe also ships a DITA capability on top of structured FrameMaker, so some libraries are already authoring DITA and using FrameMaker only as the editor. Which of the three you have changes a conversion estimate by an order of magnitude, so it is the first question to settle and it is often answered wrongly from memory.
How does FrameMaker content actually get converted to DITA?
Usually through MIF, the Maker Interchange Format, which is FrameMaker's documented text representation and can be parsed without driving the application. A sane pipeline batch-saves the estate to MIF, then transforms from there, mapping paragraph formats to elements for unstructured content or mapping the existing element tree for structured content. The transform is rarely the hard part. The hard part is that in an unstructured library the mapping is an inference from formatting, so its accuracy is capped by how consistently the original authors followed the template.
Why is so much legacy content in FrameMaker?
Because for two decades it was the serious choice. FrameMaker handled thousand-page books when Word crumbled, offered real paragraph-tag discipline and structured (SGML/XML) editions, and became the default for aerospace, industrial, and software manuals through the 1990s and 2000s. Organizations that chose it were choosing structure-adjacent discipline, which is why their libraries now convert better than Word estates, and why so many of them still exist: the tool outlived the era, and the content outlived the tool's centrality.
How well does FrameMaker convert?
It depends entirely on which FrameMaker you have. Structured Frame, authored against an EDD with real element structure, converts nearly as predictably as SGML: the mapping is mechanical and testable. Unstructured Frame is the wide middle: paragraph tags carry real signal (a disciplined template means 'Heading2' and 'Step' actually mean something), so automated conversion gets far, but the traps are characteristic: meaning carried in overrides, anchored frames and text insets, cross-reference formats, conditional text used creatively, and tables formatted by hand. The sample tells you which library you own.
DITA or S1000D as the target?
The same decision logic as everywhere else: the contract chooses S1000D (aerospace and defense deliverables under the specification and its business rules); product-family reuse across overlapping deliverables argues DITA; and a genuinely book-shaped single publication might argue staying simplest. FrameMaker libraries most often move to DITA, industrial and software content with reuse needs, but Frame-to-S1000D is routine on programs whose contracts caught up with their libraries. Pick the target before the pipeline: the mapping decisions differ meaningfully.
What does the sample-first method look like for Frame?
Same discipline as our SGML playbook, tuned to Frame's traps: a representative slice (the oldest books, the worst tables, the inset-heavy chapters, the conditional-text tangles) through the real pipeline before anyone commits. Out come the automation rate, the exception catalog (Frame's cluster in overrides, insets, and tables), and honest per-book effort for the remainder. Plus one Frame-specific pre-step that pays outsized returns: a template-consistency audit, because the conversion cost of a disciplined template and a drifted one differ by multiples.
Get In Touch
A Frame Library With a Future?
Send us a representative slice (worst tables included), and we'll return the template audit and the three numbers that make your conversion budget real.