The Word to MadCap Flare Migration Checklist (47 Steps)

How to use this checklist​

Work the phases in order. The most common Word migration failure is starting at step 25 (running the import wizard) without doing phases 1–4 — the audit, target design, mapping, and source cleanup that determine whether the import produces a clean project or a copy of the mess you were trying to leave.

Doing this yourself? The whole list applies. Hiring it out? Use it to check what your vendor actually does — the details are on our Word to Flare migration service page.

Phase 1: Audit and inventory​

• 1. Inventory every source document: file name, page count, owner, last-updated date, and whether the content is still current. Retire what nobody owns before migrating it.
• 2. List every Word style actually in use across the library, and flag unused and near-duplicate styles. Word libraries typically accumulate dozens of styles nobody applies on purpose.
• 3. Quantify direct formatting: sample documents for manual bold, italic, font, and color overrides applied without styles. This is the single biggest predictor of cleanup effort.
• 4. Audit the heading hierarchy: find skipped levels (H2 straight to H4), headings used for visual emphasis, and body text formatted to look like headings.
• 5. Inventory tables: count them, and flag fixed widths, awkward merged cells, layout-only tables, and tables that should really be lists.
• 6. Inventory non-text content: embedded images (with their effective resolution), SmartArt, equations, and OLE objects — and note which need a rebuild path, because SmartArt and equations flatten to images and OLE objects often don't survive at all.

Phase 2: Target architecture design​

• 7. Decide the topic-split heading level per document type. Heading 1 gives few large topics; Heading 2 gives many small reusable ones. Choose based on how users will navigate and how content will be reused.
• 8. Design the Flare CSS class hierarchy the Word styles will map into: fewer, semantic classes — not one Flare class per Word style.
• 9. Design the condition tag schema for audience and product variants before conversion, not after.
• 10. Plan the variable set: product names, version numbers, and company names that currently live as literal text in Word.
• 11. Define the Content and Resources folder structure and file-naming conventions for the new project.
• 12. Define an image-naming scheme. Extracted images default to image1.png, image2.png — generic names age badly.
• 13. Design page layouts for print/PDF targets: headers, footers, chapter numbering, and how Word section formatting maps to them.

Phase 3: Style and structure mapping​

• 14. Build an explicit Word-style → Flare-CSS mapping table. Every style in use gets a mapped target or an explicit "discard" decision.
• 15. Decide list handling: how mapped list styles behave, how deeply nested lists convert, and how numbered procedures that cross topic boundaries keep their numbering.
• 16. Map note, warning, and tip patterns to semantic paragraph classes (or snippet patterns) instead of ad-hoc bold text.
• 17. Map Word character styles (inline code, UI labels, emphasis) to span classes.
• 18. Decide the fate of every layout construct: text boxes, multi-column sections, and headers/footers that should become Flare page layouts.

Phase 4: Source cleanup (in Word, before import)​

• 19. Normalize the heading hierarchy: every intended topic boundary uses the chosen split level — and only that level.
• 20. Clear direct formatting on body text and reapply meaning via styles. This is the single biggest win for a clean import.
• 21. Prune unused styles from the source documents so the import maps only what matters.
• 22. Fix broken cross-references and field codes (StyleRef, page-number refs) in Word — unfixed, they arrive in Flare as static text.
• 23. Convert layout-only tables to real lists or paragraphs, per the phase 1 audit.
• 24. Mark variant content in source (comments, hidden text, or custom markers) so conversion rules can apply condition tags automatically.

Phase 5: Pilot conversion​

• 25. Pick one representative document — not the cleanest one, the most typical one.
• 26. Run the Flare Word import with the style mapping and the chosen topic-split level.
• 27. Build every output target from the pilot and review topics, styles, tables, lists, images, and links in the actual outputs.
• 28. Adjust the mapping and transform rules and re-run until the pilot converts cleanly. The problems in one document are the problems across the library.

Phase 6: Full conversion​

• 29. Batch the remaining documents and convert them against the same rule library, most-representative batches first, so the architecture stays consistent.
• 30. Apply post-import transform rules: normalize fixed table widths for HTML5 output, repair list numbering across topic splits, and strip leftover inline styles.
• 31. Apply condition tags from the source markers set in step 24.
• 32. Replace literal product, version, and company strings with the Flare variables planned in step 10.

Phase 7: Reuse — snippets​

• 33. Detect passages duplicated across converted topics: warnings, boilerplate, repeated procedures. These are your snippet candidates.
• 34. Extract shared content into snippets and replace the inline copies, so the next edit happens in one place.

Phase 8: TOCs and targets​

• 35. Build the TOC (or TOCs) around how users navigate — not around the old document boundaries.
• 36. Configure each target (HTML5, PDF, and any others) with the page layouts and settings designed in phase 2.
• 37. Bind condition expressions to targets and verify each audience/product variant builds exactly the right content.
• 38. Configure target-level details: search, skin and branding, output paths, and favicons/logos.

Phase 9: Links and cross-references​

• 39. Rebuild Word cross-references as Flare cross-references so they update automatically instead of drifting as static text.
• 40. Convert intra-document bookmark links into proper topic and bookmark links.
• 41. Run link validation across the whole project and fix broken or ambiguous links before anyone starts authoring.

Phase 10: Images and assets​

• 42. Rename extracted images to the naming scheme from step 12 and update all references.
• 43. Rescale or replace images whose pasted-in resolution is too low for modern HTML5 output.
• 44. Rebuild SmartArt, equations, and embedded objects per the phase 1 rebuild plan: SVG for diagrams, images with alt text for equations, native equivalents for objects.

Phase 11: QA and build​

• 45. Run the full QA pass: build every target with all errors and warnings triaged to zero, and check condition coverage, snippet usage, image references, and page-layout bindings.
• 46. Spot-check output fidelity against the Word source for a sample of every document type — page by page, not just a skim.

Phase 12: Cutover​

• 47. Cut over: freeze the Word source, archive the originals read-only, hand over the style-mapping documentation and project playbook, and publish from Flare from day one.