FrameMaker to MadCap Flare Migration
FrameMaker projects rarely "just import." Structured FrameMaker, unstructured FrameMaker, MIF, anchored frames, cross-references, conditional text, and Reference Pages each have their own conversion gotchas. We've migrated 500,000+ pages — here's what survives the import, what doesn't, and what to fix before you run the wizard.
What imports cleanly from FrameMaker
MadCap Flare has the most mature FrameMaker import in the industry. For both structured (EDD/DITA) and unstructured FrameMaker, the import wizard reliably handles:
- Paragraph and character formats mapped to CSS classes.
- Chapter and book hierarchy converted to Flare topics with TOC entries.
- Variables mapped onto Flare variables (sometimes with manual remediation of naming collisions).
- Conditional text mapped onto Flare condition tags (flat mapping — see the next section).
- Cross-references converted to Flare cross-references, when the source uses cross-reference markers (not inline anchors).
- Indexes and marker types.
- Tables, including most cell-level formatting.
For straightforward FrameMaker projects under 200 pages with a single book file and no Reference Page customization, the wizard often produces a usable Flare project in a single pass. Most real-world projects are not that.
What does not survive the import
Anchored frames containing multiple graphics, callouts, or runaround text often arrive as flattened images or break apart. Vector overlays, in particular, don't survive — they need rebuilding as SVG or as Flare drop-down/expanding-text content.
FrameMaker's Reference Pages, master pages, and template behavior don't map cleanly to Flare's master-page / page-layout model. Generated content (running headers, page numbers, chapter titles) usually needs to be rebuilt in Flare page layouts.
FrameMaker cross-reference formats (the "see [chapter] on [page]" templates) come over as static text. Flare uses xref formats from its stylesheet — they need to be redefined, then cross-references rebound.
FrameMaker shows/hides by conditional-text expression. Flare evaluates conditions per target. Multi-condition expressions (Audience AND Product NOT Internal) need to be rebuilt as Flare target condition include/exclude logic.
FrameMaker's autonumber properties (continue numbering across pages, restart at section, etc.) don't transfer. Long procedural docs need Flare list-style rebuilding to keep numbering correct.
FrameMaker equations, anchored OLE objects, and custom markers arrive as images or are lost entirely. If your docs rely on these, plan a rebuild path before conversion.
Pre-migration cleanup checklist
Each item below takes minutes to check in FrameMaker and saves days of post-migration rework in Flare. Run through them before you open the import wizard.
- Resolve all unresolved cross-references. Unresolved xrefs in FrameMaker become broken links in Flare. Fix them at source.
- Update the book. Run File → Update Book and resolve any reported issues before exporting MIF or running the Flare import.
- Inventory paragraph and character formats. List every format, what it's used for, and which Flare CSS class it should map to. The wizard will create one class per format if you don't supply a mapping.
- Inventory variables. Note naming collisions and decide which become Flare variables and which become snippets.
- Inventory conditional text. List every condition and what it controls. Plan the Flare condition tag schema — usually multiple tag sets, not one.
- Audit anchored frames. Identify frames with multiple objects, vector overlays, or complex runaround. Decide which to flatten before import, which to rebuild as SVG, and which to rebuild as Flare drop-down or expanding text.
- Audit Reference Pages. Document any generated content, custom page numbering, and chapter-title behavior. This becomes the Flare page-layout spec.
- Convert legacy MIF. If you're working from MIF files older than FrameMaker 9, round-trip them through a recent FrameMaker version first. Older MIF has encoding quirks that cause silent issues in Flare.
- Test with one full book. Pick the most representative book in your library and run the full conversion on it. Build every target type you need. Review the output carefully. The problems you find in one book will be the same problems across the rest.
- Document your mappings. Create a mapping document that records how each FrameMaker element translates to its Flare equivalent. This becomes the operational playbook your writers use on day one.
Recommended migration workflow
Audit
Inventory paragraph formats, character formats, variables, conditions, anchored frames, Reference Pages, and cross-reference formats. Identify what's structurally broken before conversion.
Target design
Define the Flare project structure: CSS class hierarchy, condition tag schema, page-layout spec, master pages, and TOCs/targets. The conversion converges on this design.
Source cleanup
Resolve cross-references, update the book, prune unused formats and conditions, and convert legacy MIF. Cleaner source produces a cleaner import — every time.
Scripted conversion
Run the Flare import with the mapping from step 2, then apply transform rules: collapse callout variants into snippets, rebuild xref formats, restructure conditions, and normalize images.
Validation and handover
Link integrity, condition coverage, snippet usage, image references, page-layout bindings, and target builds — all checked before any writer touches the Flare project. Then mapping docs + playbook delivered.
Typical timeline and risk profile
A typical FrameMaker-to-Flare migration of a 1,500-page library (across 5 to 10 book files) runs 4 to 8 weeks end-to-end. Structured FrameMaker (EDD/DITA) is usually faster to convert than unstructured FrameMaker, because the source structure is already explicit.
The two highest-risk items in a FrameMaker migration are usually:
- Anchored frames with vector overlays. Plan a rebuild path early; don't discover this in week 6.
- Conditional text rearchitecture. If you have more than five conditions doing more than one job each, design the target Flare condition schema before conversion, not after.
Engagements typically start at $5,000. Final scope depends on book count, page count, condition-text complexity, anchored-frame complexity, and how many output targets you need configured.
I can't thank you enough for this plugin. What a life saver! I am in the process of migrating 3 extensive product manuals from markdown to Flare, and it's just a breeze with your plugin. I can even replace tags on a page to apply different formatting. The content comes over so clean and beautiful, there's hardly any post-import work to do. I am extremely grateful and can only recommend this to anyone having to make the move from markdown to Flare.
Frequently asked questions about FrameMaker to Flare migration
Does Flare's FrameMaker import support structured (EDD/DITA) FrameMaker?
Yes. Flare imports both structured and unstructured FrameMaker. Structured FrameMaker is usually faster to convert because the source structure is already explicit, which means transform rules have a cleaner starting point. Unstructured FrameMaker requires more upfront mapping work for paragraph and character formats.
Do we need to convert FrameMaker to MIF first?
No — Flare imports native FrameMaker .fm and .book files directly in most cases. MIF is useful when you're working from an older FrameMaker version that the current Flare can't open, or when you want to preprocess source content with a text-level transform before import.
What happens to anchored frames with multiple objects and callouts?
They usually arrive flattened or break apart. Vector overlays don't survive. The fix is to identify them in the pre-migration audit and plan the rebuild path — typically as SVG (for graphics with text overlays) or as Flare drop-down or expanding-text content (for callouts on procedural graphics).
How do FrameMaker conditional text expressions translate to Flare?
FrameMaker evaluates expressions on the document; Flare evaluates conditions per target. Single-condition mappings translate cleanly. Multi-condition expressions (A AND B NOT C) need to be rebuilt as Flare target condition include/exclude logic, usually across multiple tag sets rather than one flat condition list.
Can you handle very large FrameMaker libraries (10,000+ pages)?
Yes. Multi-book libraries are usually staged into batches with the most representative book converted first to validate the transform rules. Later batches are converted against the same rule library, which keeps the architecture consistent across the full library.
What if our FrameMaker project still has files from FrameMaker 7 or earlier?
Round-trip them through a current FrameMaker version first to normalize the file format. Older MIF and .fm files have encoding and structural quirks that cause silent issues during Flare import. We handle this as part of the pre-migration cleanup step.
Send one FrameMaker book. We'll show you exactly what your migration will look like.
500K+ pages migrated · 17+ years · Typical FrameMaker projects from $5,000 · 4–8 weeks for a typical 1,500-page library.
Back to MadCap Flare migration services · Related: MadCap Flare conversion.