A knowledge base isn't just a place to dump help articles anymore. It's what your support team deflects tickets with, what new hires learn the product from, and — increasingly — what your AI agents actually run on. Rovo and every other AI-driven support layer is only as good as the KB underneath it: fragmented articles, duplicate content across three different tools, and inconsistent structure don't just confuse your support team; they confuse the AI trying to answer from that content. If you're feeding a KB into Rovo agents or any retrieval-based assistant, messy structure translates directly into bad answers.
That's why knowledge base consolidation usually comes up in the same breath as a help desk migration. Teams end up with knowledge scattered across a help desk's built-in KB, a wiki nobody maintains, and a handful of Google Docs — and moving to JSM is the natural point to pull it all into one Confluence instance instead of migrating the mess as-is. Done well, that consolidation gives you one clean source of truth: better for your support agents, better for self-service, and better for any AI layered on top of it.
But consolidation only pays off if you actually understand what survives the move and what doesn't. Picture this: you're migrating your help desk into Jira Service Management, and somewhere in the plan is a line that says ‘knowledge base → Confluence.’ It sounds like a footnote. It isn't.
Your KB has structure your support team — and now your AI tools — rely on: categories, nested folders, authorship, attachments — and Confluence doesn't have a slot for every piece of that structure by default.
Here's what actually happens to your KB content when it lands in Confluence, and what you need to rebuild by hand.
What moves natively
- Articles → Pages: Your KB articles convert directly into Confluence pages, with attachments carried along.
- Categories → Spaces: Top-level categories from your source KB become Confluence Spaces — this is the one structural layer that maps cleanly out of the box.
- Folder names → Tags: This is the part that trips people up: subfolders don't become a nested page tree. By default, the folder name gets added to each page as a tag, and all the articles that folder contained land as flat, top-level pages inside the destination Space.
So if your knowledge base structure is Category → Folder → Sub-folder → Article, only the Category survives as real structure (a Space). Everything under it gets flattened, with the folder path preserved as metadata rather than hierarchy.
What you need to rebuild or configure
- Nested hierarchy: If a flat page list with folder tags isn't good enough — if your team actually navigates by that folder tree — you need custom scripting to rebuild it: source category becomes the Space, source folder becomes a parent page, and each article becomes a child page underneath it. This isn't something a standard migration run does for you.
- Article authorship: By default, every migrated page gets attributed to the account that ran the migration, not the person who actually wrote the article. Nobody notices until someone asks why the IT director apparently wrote 400 troubleshooting guides overnight. Fixing this means re-assigning ownership through the API after import, and it depends on the source author's account actually matching to a target user first.
- User matching, generally: Worth being precise here: matching isn't some rigid automatic process happening invisibly — the migration tool lets you configure how source users map to target users based on what your environment actually needs. Article authorship, comment attribution, and access all depend on getting that mapping set correctly before you run the import, not after.
- Permissions and space access. Confluence's permission model doesn't map 1:1 to whatever access rules governed your source KB. Expect to set Space permissions manually rather than assume they carried over.
Where a dedicated tool helps
If your source is Zendesk, Freshdesk, Freshservice, or a similar help desk and the target is Jira Service Management plus Confluence for the knowledge base, this is squarely what Help Desk Migration by Relokia is built for — it handles the ticket-and-KB side of this move together, including the category-to-Space and article-to-page conversion described above.
Worth a look specifically because this cross-platform KB conversion isn't something Atlassian's own Confluence tooling does — Atlassian's Migration Assistant is for moving existing Confluence content between Confluence instances, not for importing external help desk articles in the first place.
A migration sequence worth following
- Map your structure first: Know which source categories become which Spaces before you run anything — this is your one chance to get the top-level structure right without manual cleanup after.
- Decide on hierarchy up front: If flat pages with folder tags are fine, you're done. If you need real nested pages, plan the custom build before migration day, not after your team starts asking where the folder tree went.
- Set user matching deliberately: Configure how authors and agents map to target accounts before import, especially if authorship accuracy matters to your team.
- Migrate, then spot-check: Pull a sample of articles across a few categories and verify: page content, attachments, tags, and author attribution.
- Fix authorship second: Since it defaults to the migration account, run the re-attribution step as a deliberate follow-up, not an afterthought.
Bottom line
Articles and categories move cleanly — pages and Spaces are a solid default. Folder structure and authorship don't survive automatically; they land as tags and admin-attributed pages unless you plan for them.
What's your knowledge base structure look like — flat categories, or deep folder trees? That's usually the deciding factor in how much rebuild work you're signing up for.
