How to migrate from Confluence to Topicary (2026)

How to migrate from Confluence to Topicary

If per-seat licensing is what brought you here, this is the practical part: how to get your content out, exactly which macros survive, and how to rebuild in Topicary without overselling you. If the decision itself is still open, read the Topicary vs Confluence comparison first. That piece is honest about when staying on Confluence is the right move.

One framing before you start: Confluence is a wiki, so every page is a standalone copy. That fact makes the migration simpler than it sounds. There is almost no structural metadata to preserve, because a wiki never had any. Your content comes out as page bodies and lands cleanly. The reuse and conditions layer gets built once, in Topicary, on purpose. It's also worth running a quick audit of the space first: a migration is the best possible moment to leave the dead pages behind.

First, decide whether you should move at all

The most expensive migration is the one you didn't need. Be honest about why you're leaving Confluence. The reason decides the answer.

Stay on Confluence if your company is committed to Atlassian and your docs genuinely benefit from sitting next to Jira. Stay if Scroll includes cover your reuse and the per-seat cost is acceptable. K15t's apps are mature and well-supported. "We already have Confluence" is a real advantage, not an excuse. If only the budget hurts, the simpler fix may be a cheaper Confluence plan or fewer add-ons.

Move to a CCMS like Topicary when cost isn't the only problem. Look for these signals:

• The same passage (a prerequisite, a safety note, support boilerplate) is pasted across dozens of pages. Updating it means hunting every copy.
• You publish (or want to publish) docs for multiple product versions. A space or page tree per version duplicates everything.
• You need to target different audiences, platforms, or tiers from one source, not visitor-side toggles.
• You need a branded PDF and a web portal from the same content.

If two or more are true, a CCMS is an upgrade rather than a lateral move. The rest of this guide is for you.

Why teams are leaving Confluence in 2026

The trigger is usually licensing math. Confluence bills per user, so the bill tracks your headcount, not your writing staff. You can end up paying for hundreds or thousands of seats to serve a docs team of five. Teams adopt K15t apps to make Confluence work as a documentation platform. Those apps charge a second per-user fee on top of the Confluence seat. Scroll Versions is for product-version docs, Scroll Viewport for a public site. As the org grows, that combined per-seat bill gets hard to defend for a documentation use case. (Pricing shifts regularly; check Atlassian's current pricing and your K15t app costs before you model it.)

The quieter reason is structure. A wiki is strong for collaborative internal notes. It is weak for product documentation that needs single-sourcing and versioning. Scroll add-ons retrofit part of that. Reuse still stays page-level, and product-version docs still depend on an add-on you license per user. When the cost pressure and the structural ceiling arrive together, that's the CCMS case.

Before you export: audit the space

Don't start the export until you know what you have. An inventory makes the rebuild faster. It also tells you what won't survive the trip.

• Page count: across how many spaces. This drives your timeline. Confluence spaces routinely run to hundreds of pages.
• Macro inventory: list the macros you rely on. Info/warning/note and code macros convert; Jira, dynamic-content, and third-party macros do not (see the next section). Flag macro-heavy pages now.
• Reuse: note where you use Scroll includes or duplicated passages; these become Topicary components.
• Versions: if you use Scroll Versions, note how versions are organized; you'll rebuild this as conditions plus a version selector.
• Attachments: images embedded in pages transfer. Standalone file attachments do not, so list any you'll need to re-upload.
• What to leave behind: pages untouched in over a year, drafts, duplicates, Jira-board pages. Every page you don't migrate is one you never have to clean up. Cut them before exporting.

Step 1: Export your space as HTML

In Confluence, go to Space Settings → Content Tools → Export, choose HTML, and export. Confluence generates a .zip containing your pages and their hierarchy.

Two things to know:

• You need Space Admin or Site Admin permission to export a space. If you do not have it, this is the step where you ask for access.
• Use the HTML export, not XML. Confluence's XML export is a backup/restore format, not a content-migration format. The importer expects HTML.

Export the whole space in one pass so the page tree comes across intact.

Step 2: Import into Topicary

1. Go to Topics and click Import (import is available on Pro, Team, and Business plans).
2. Select the Confluence .zip.
3. Review the preview cards the importer shows for each detected page.
4. Check "Create a map from folder structure" to preserve the Confluence page hierarchy as a Topicary map.
5. Click Import.

The importer strips Confluence page chrome (navigation, sidebars, breadcrumbs) and converts macros to their closest equivalents as it goes.

Step 3: Verify what transferred and what to clean up

Spot-check the result. The body content lands cleanly. The macro layer is where the work is.

What transfers: headings, paragraphs, ordered and unordered lists, tables, embedded images, and basic formatting. The page tree becomes your map nesting.

What converts:

What does not transfer (plan to reconstruct or drop these):

• Jira macros and links: removed entirely.
• Dynamic-content macros (user lists, activity feeds, database queries): removed.
• Third-party / custom Marketplace macros: removed.
• Page restrictions, author names, modification dates, and labels: not imported (re-apply labels as tags after import).
• Standalone attachments: only images embedded in page content survive; re-upload the rest.
• Deeply nested lists: very deep nesting may flatten by a level or two.

A useful cleanup shortcut: pages that were entirely macros (a Jira board, a dynamic report) import as Empty topics. Nothing survived, because nothing on the page was content. After import, filter the Topics list for Empty and delete them in one pass.

Step 4: Build the structure layer Confluence couldn't

This is the payoff: the reason you moved to a CCMS instead of another wiki. With the content in, do what the page model never could:

• Turn repeated passages into components. Select text → "Save as component." That prerequisite or safety note now lives in one place. You get where-used tracking and orphan detection. Edit once, and see every affected topic before you commit the change. (This is the single biggest upgrade over Scroll includes: you get a real where-used view.)
• Add conditions for product versions and audiences. Tag content by product version, platform, or tier. Preview filtered in the editor, then publish separate outputs from one source. This is the native replacement for Scroll Versions: built into the content model, not licensed per user.
• Define variable sets. Replace hard-coded product names, URLs, and version strings with named variables that switch per publication target.
• Turn on the version selector. Publish multiple versions and readers get a header dropdown to switch between them. The full how-to is here.

Step 5: Validate and publish

Before you point any public URL at the new site, run the checklist:

• Spot-check 10 to 15 topics across sections: formatting, heading levels, tables, and that images render.
• Review every macro-heavy page: confirm info/warning/note became callouts and that no Jira/dynamic content was silently lost.
• Delete the Empty topics left by macro-only pages.
• Open each new component and confirm the "Where Used" count is right.
• Preview with conditions applied: toggle each version/audience and verify the right content shows and hides.
• Publish to a draft URL, walk every page, and check the map hierarchy matches your old Confluence tree.

Keep Confluence live during this period. Run both in parallel until every section checks out. Then switch.

Realistic timelines

These assume one person. The import itself is fast. The time goes to reconstructing macro-heavy pages, rebuilding reuse as components, and re-creating versioning as conditions. Component and condition work is optional at migration time. Land the content first. Add the structure gradually.

What you gain after migration

• Flat, author-based pricing. You pay for the handful of people who write, not for every employee with a seat. Reviewers are free. The cost pressure that pushed you off Confluence doesn't follow you.
• Real content reuse. Components with where-used tracking and orphan detection: a genuine upgrade over Scroll includes.
• Native product-version docs. Conditions plus a reader version selector, built in, with no per-user add-on.
• Multi-format output. Web, branded PDF, and Markdown from one source, plus LLM-ready output (llms.txt, .md URLs, an AI query endpoint) on every published site.

Currently free during beta. Join here. For the full feature and pricing breakdown, see Topicary vs Confluence. To set up versioned docs after you land, see how to version product documentation.

Disclosure: This guide is published by Topicary. I compete with Confluence and K15t and have a commercial interest in teams migrating. So I've tried to be straight about when staying on Confluence is the better choice, and about exactly which macros do and don't survive the export. Confluence and K15t pricing shifts regularly; verify current costs against Atlassian's pricing before modeling your own. Found an error? Email support@topicary.com and I'll correct it within 24 hours.