Migrate from MadCap Flare to Topicary (2026)

How to migrate from MadCap Flare to Topicary

Migrating from MadCap Flare is not as painful as it looks. A Flare project is a folder of XML files with known structures (topics, snippets, TOC, variables, conditions, targets, skins), and Topicary's importer reads all of them. If you are not yet familiar with what a CCMS is, that guide explains the component-based model Topicary uses. The automated import takes under a minute and transfers content with high fidelity. Inline conditions, cross-references, images, downloads, snippet references, variables (with per-target overrides), TOC hierarchy, and your publication targets all come through, including each target's boolean condition expression and branding. The remaining manual work is reviewing the imported targets and restructuring any content that relied on Flare-specific interactive elements like drop-downs or expanding text.

This guide walks through the entire process, from auditing your Flare project before you export it to validating the migrated content in Topicary. If you are evaluating whether to migrate at all, read the detailed Topicary vs MadCap Flare comparison first.

Why teams are leaving Flare in 2026

The primary reason is pricing. MadCap discontinued perpetual licenses; new customers must subscribe at $3,150/yr for each seat (madcapsoftware.com/pricing/, checked August 2026). Multiple Flare customers on r/technicalwriting reported a 45% renewal price increase in late 2025, with renewals hitting in early 2026. One user described the situation bluntly: "MadCap wants to increase their rates by a whopping 45%, and I have been asked to look around for alternatives." Another confirmed the same renewal timeline and extension length.

Vendr procurement data (checked May 2026) reports a ~9% annual uplift on MadCap subscription renewals as standard practice (vendr.com). A 5-writer team paying list price spends $15,750/yr on Flare desktop licenses alone, before adding Flare Online for cloud hosting, review, and AI features.

The price increase is the trigger, but it is not the only reason. Teams also cite Flare's Windows-only desktop requirement (Mac users need Parallels), the learning curve (Capterra Ease of Use: 3.5/5 across 21 reviews, checked May 2026), and Git-based collaboration friction as factors pushing them toward cloud-native alternatives.

Where Flare migrations lose their structure

Most modern destinations are Markdown-based: Fern, Mintlify, GitBook, Docusaurus. They produce clean web docs, but they have no place to put your structure. When you migrate a Flare project into them, your snippets, variables, and conditions don't move across as reusable, conditional, single-sourced objects. They get flattened into plain text inside each topic. One technical writer described migrating Flare to Fern this way: "I had a lot of snippets, variables, and conditional content that just became part of the topics when they were migrated", then spent days rebuilding the structured layer by hand.

That's the difference between migrating to a docs platform and migrating to a CCMS. Topicary imports the Flare project with its structure intact: snippets become components (with reference tracking), condition tags become dimensions, variables stay variables, the TOC becomes a map. You keep the single-sourcing you spent years building, instead of paying to throw it away. The rest of this guide is that import.

Before you export: audit your Flare project

Do not start the import until you know what you have. Migrations that skip the audit phase are the ones that go over budget. Improvementsoft reports that roughly 80% of CCMS migrations run over budget or over schedule, primarily because teams migrate first and discover structural problems later.

Take inventory of your content

Open your Flare project and document the following:

• Topic count: how many HTM files live in your Content folder
• Snippet count: how many .flsnp files you have and where they are referenced
• Condition tags: which dimensions you use (audience, platform, product) and whether you rely on boolean expressions (AND/OR/NOT)
• Variable sets: how many .flvar files and whether you use system variables (page numbers, dates) or target-level overrides
• TOC files: how many .fltoc files, and whether they reference topics across multiple projects through Global Project Linking
• Custom stylesheets: any CSS overrides beyond Flare's defaults
• Micro content: any micro content topics that power search results or chat widgets
• Target count: how many publishing targets you maintain (HTML5, PDF, Word, and others)

Decide what to leave behind

Every piece of content you do not migrate is content you never have to restructure, maintain, or troubleshoot in the new system. Improvementsoft's migration consultancy recommends budgeting 20 to 30 percent of total migration time for validation and cleanup. Cutting dead content before import reduces that budget significantly.

Look for topics that have not been updated in over a year, snippets that are referenced zero times (Flare's "Used By" column in the File List shows this), and condition tags that no active target uses. Archive or delete these before exporting.

Step 1: Export your Flare project as a zip

Locate your .flprj file and the enclosing project folder. A typical Flare project folder looks like this:

MyProject/
├── MyProject.flprj
├── Content/
│   ├── Topics/
│   │   ├── getting-started.htm
│   │   ├── installation.htm
│   │   └── ...
│   └── Resources/
│       ├── Snippets/
│       │   ├── copyright-notice.flsnp
│       │   └── ...
│       └── Stylesheets/
│           └── MainStyles.css
└── Project/
    ├── TOCs/
    │   └── OnlineOutput.fltoc
    ├── Variables/
    │   └── General.flvar
    └── Targets/
        ├── HTML5.fltar
        └── PDF.fltar

Zip the entire folder. The Content and Project subdirectories must both be included. Topicary needs the .flprj file to identify the project, the Content folder for topics and snippets, and the Project folder for TOC structure, variables, and conditions.

If your project uses Global Project Linking across multiple Flare projects, zip each project separately. Each one must be imported as its own Topicary project.

Step 2: Import into Topicary

Open the Topicary import dialog (drag the zip file onto the editor, or use the import button in the project toolbar). Select "MadCap Flare" as the source format. Topicary's importer parses the project structure and shows a preview before committing anything:

• Topics detected: count and list of HTM files that will become Topicary topics
• Components detected: snippets (.flsnp files) that will become reusable components
• Variables: variable sets with key-value pairs
• Conditions: condition dimensions and values extracted from .flcts files, with Flare colors preserved
• Cross-references: MadCap:xref elements resolved to topic links
• Images and downloads: extracted from the zip and uploaded to project storage, with src and download links rewritten
• TOC hierarchy: map structure with nesting preserved, master TOC selected from .flprj
• Publication targets: each .fltar becomes an (unpublished) publication target, with its condition expression, variable overrides, and homepage
• Branding: skin favicon and logo, stylesheet brand color tokens, and web font

Review the preview. If the counts look wrong (far fewer topics than expected, or zero snippets when you know you have them), check that your zip includes the full project folder structure. The importer expects the Content and Project directories at standard paths relative to the .flprj file.

Step 3: Verify what transferred

After the import completes, open the project in Topicary and check these 5 areas.

Topics

Each Flare HTM file becomes a Topicary topic. The importer preserves heading structure (H1 through H6), paragraphs, ordered and unordered lists, tables, images, and code blocks. Inline formatting (bold, italic, code, links) carries over. Cross-references (MadCap:xref) become resolved topic links pointing to the correct imported topic. Inline conditions (MadCap:conditions attributes) become conditional blocks and inline conditions with the correct dimension and value assignments.

What does not carry over: Flare-specific interactive elements like MadCap:dropDown, MadCap:expanding, MadCap:toggler, and MadCap:popup are stripped during import. Content inside these elements is preserved as plain paragraphs, but the collapsible or interactive behavior is lost. If your project relies heavily on dropdown sections, plan to restructure those topics manually.

Components (snippets)

Flare snippets (.flsnp files) become Topicary components. Every reference relationship is preserved: if a topic referenced a snippet in Flare, the corresponding Topicary topic will contain a component reference to the imported component.

Check the component "Where Used" list in the Components panel to verify reference counts match your expectations. Orphaned components (referenced zero times) may indicate broken references that need manual reconnection.

TOC structure (maps)

The .fltoc file becomes a Topicary map with nesting preserved. Topic order, hierarchy depth, and grouping all transfer.

TOC entries that pointed to external URLs, PDFs, or other non-topic resources will appear as placeholders. Review the map and remove or replace these entries.

Variables

Variable sets (.flvar) transfer as key-value pairs. Open the Variables panel and confirm that variable names and default values match your Flare project.

Per-target variable overrides transfer too. If a "ProductName" variable resolved differently in your internal versus customer-facing targets, those overrides come across on the corresponding publication targets. What does not transfer: system variables (page numbers, build dates, heading text) and date/time variables, which have no static equivalent.

Conditions

Condition tag sets (.flcts files) become Topicary condition dimensions and values, with Flare's color assignments preserved. If your Flare project had a "Platform" condition set with values "Windows", "macOS", and "Linux", Topicary will create a "Platform" dimension with those 3 values and their original Flare colors.

Inline conditions (the MadCap:conditions attribute applied to content elements) transfer automatically. Content tagged with conditions in the Flare editor appears as conditional blocks or inline conditions in the Topicary editor, with the correct dimension and value already assigned. This includes conditions on content inside snippets.

Target condition expressions transfer too. Each Flare target's ConditionTagExpression (including boolean exclude[A or B] / include[…] logic) is translated into a condition profile on the matching Topicary publication target, so your audience/output split (for example OSS vs. Enterprise) is reconstructed automatically rather than rebuilt by hand. The importer flags any expression it could not fully resolve in the import result, so review those.

Two honest caveats remain. First, Topicary applies conditions at the block level, not within a sentence: Flare's inline-level tagging (hiding a phrase mid-paragraph without splitting it) has no equivalent. Second, very complex mixed AND/OR/NOT expressions across 5+ overlapping dimensions may need review after import. Teams that rely on that depth should read how the comparison page describes the condition model before committing.

Step 4: Review what transferred, recreate what didn't

Most Flare content (including your targets and branding) transfers automatically. Review the imported pieces, then recreate the genuinely platform-specific items.

Publishing targets

Flare targets (.fltar files) now import as Topicary publication targets, one per .fltar, created unpublished for you to review. Each carries its condition expression (so the audience/output split is reconstructed), its variable overrides, its homepage, and, for PDF targets, cover and table-of-contents settings. Your job is to review and publish, not rebuild:

• Web output: open the imported target, confirm its condition profile and branding, and publish. Topicary hosts the site for you, with no S3, Netlify, or FTP configuration needed.
• PDF output: the imported PDF target carries cover and TOC settings; add running headers, footer text, and font selections as needed. Note: if your Flare PDF targets relied on auto-numbering, back-of-book index generation, or master page layouts, those features do not exist in Topicary's PDF engine and need a different approach.
• Markdown export: available for any map or individual topic. Useful for feeding documentation into developer workflows or static site generators.

Branding, stylesheets, and skins

Branding now imports automatically: the skin's favicon and brand logo, the master stylesheet's :root brand color tokens, and the web font are applied to your project settings. What does not carry over: the full Flare stylesheet (its mc-* selectors target Flare's own DOM and would not apply), skin navigation chrome (Topicary generates its own site template), and a single "primary" brand color (Flare has no dedicated brand-color field, so set one in Branding). For deeper customization, the Team plan includes a custom CSS field that applies to published sites.

If your Flare project had extensive CSS customization for PDF output (custom page margins, font stacks, column layouts), those need to be reapplied through Topicary's PDF configuration options or custom CSS.

Micro content

Flare's micro content feature (short answer snippets that power search results and AI chat) has no direct equivalent in Topicary. Consider converting micro content topics into standard FAQ-style topics. Topicary's published sites include AI-powered search that extracts answers from your existing content, which covers much of the same ground without requiring dedicated micro content entries.

Interactive elements

Flare's MadCap:dropDown, MadCap:expanding, MadCap:toggler, and MadCap:popup elements are converted to plain paragraphs during import. The content is preserved but the collapsible or interactive behavior is lost. If your project uses these extensively, plan to restructure those sections into separate topics or use Topicary's callout blocks for important notes.

Step 5: Validate and publish

After recreating your publishing targets, run through a validation checklist before publishing.

• Spot-check 10 to 15 topics across different sections. Verify formatting, heading levels, list structure, and that images render correctly.
• Open every component and confirm its content matches the original Flare snippet. Check the "Where Used" count.
• Check cross-references. Open a topic with Flare cross-references and confirm they link to the correct imported topics.
• Preview with conditions applied. Toggle each condition dimension in the editor and verify that the correct content appears and hides. Confirm condition colors match your Flare project.
• Replace variables. Open a topic that uses variables and confirm they resolve to the expected values.
• Publish a test site. Publish to a draft URL, navigate every page, and check that the TOC hierarchy matches your expectations.
• Generate a test PDF. If you use PDF output, generate one from your main map and compare it against your Flare PDF. Note the formatting differences you can live with and the ones you cannot.

For large projects (200+ topics), consider a phased migration: import the full project, validate and publish one section at a time, and use the old Flare site as the reference while you work through each section. Improvementsoft recommends budgeting 20 to 30 percent of the total migration time for validation and cleanup. This is not wasted time; it is the phase that prevents problems from reaching your readers.

Realistic timelines

Migration timelines depend on project size and how heavily you use Flare-specific features. Here are realistic estimates based on the import capabilities and what requires manual work.

These estimates assume one writer doing the migration work. Manual cleanup time is primarily spent reviewing the imported publishing targets and restructuring any content that relied on Flare-specific interactive elements. Conditions, cross-references, snippets, variables, images, downloads, targets, and branding all transfer automatically. With a second writer handling validation while the first continues cleanup, you can compress the medium and large timelines by roughly 30%.

What you gain after migration

The migration effort buys you a permanent shift in how your team works:

• No more merge conflicts. Multiple writers work on different topics simultaneously in the browser. No Git, no SVN, no source control overhead.
• Hosted publishing with zero infrastructure. Publish and the site is live, with dark mode, full-text search, AI search, and reader feedback included. No servers to deploy or CDNs to configure.
• SME review without barriers. Generate a review link, send it to your subject matter expert. They open it, read, comment, and approve, with no account, no install, no training.
• LLM-ready output. Every published site automatically generates llms.txt, .md page URLs, sitemap.md, and an AI query endpoint. Your documentation is consumable by AI agents out of the box.
• Predictable pricing. Topicary Team covers up to 10 authors at $149/mo ($1,788/yr). No per-seat licensing, no hidden Flare Online add-on costs. For comparison, 5 Flare desktop seats cost $15,750/yr before Flare Online. Currently free during beta. Join here.

For a deeper look at what each tool does better and the honest trade-offs, read the full Topicary vs MadCap Flare comparison. To understand how Topicary fits into the broader CCMS market, see Why I Built Topicary.

Disclosure: This guide is published by Topicary. I compete with MadCap Flare and have a commercial interest in teams migrating. I have tested the Flare importer against real Flare projects and cite specific sources for every factual claim. All pricing checked against madcapsoftware.com/pricing/ on May 26, 2026. If you find an error, email support@topicary.com and I will correct it within 24 hours.