Merging Confluence and Notion knowledge bases after add-ons

What gets lost when a wiki moves between tools?#

A wiki migration most often loses the context around pages rather than the pages themselves. Body text usually survives. What disappears is the version history that shows how a runbook changed, the comment threads where engineers argued about it, the attachments it pointed to and the permissions that kept some of it private.

Confluence and Notion model content differently. Confluence organizes pages into spaces, with macros that pull in Jira issues or other pages, while Notion mixes pages with databases, relations and properties. Exports and importers from both vendors and from third parties handle these elements differently and change over time, so test on a representative space and check current vendor documentation rather than assuming.

The native exports also have limits worth planning around. Atlassian says a Confluence Cloud site backup, created by an admin in the Backup manager, includes attachments only if selected, skips soft-deleted spaces in the trash, keeps its download link for 14 days and stores only one backup at a time, so each new backup overwrites the last. Notion says a full workspace export, in HTML, Markdown or CSV, can take up to 30 hours and that the emailed download link expires after 7 days. Schedule exports so someone is ready to download and verify them inside those windows.

Decide the destination before moving a single page#

The destination decision comes first because it shapes every later step. Most software holdcos standardize on whichever tool the platform's engineering teams already link to from their issue tracker, then decide space by space whether acquired content moves, stays federated for a period, or goes into a read-only archive.

A wiki merge is not the moment for a cleanup. Restructuring, renaming and deleting during migration make it impossible to verify that nothing was lost. Move first, verify, then let the owning teams prune. These questions sort each acquired space:

• 1Which spaces or teamspaces are opened every week, and by whom?
• 2Which pages are linked from tickets, alerts, runbooks or code comments that will keep being used?
• 3Which content is specific to one product and will stay with that product's team?
• 4Which content is obsolete but documents decisions, incidents or customer commitments worth keeping?
• 5Which pages are confidential and need a restricted home, or no home at all, in the shared wiki?

Checklist for merging an acquired knowledge base#

A merge checklist keeps each acquired workspace on the same path: freeze, export, separate, test, migrate, verify and only then close the source. Assign a named owner on each side who signs off before the acquired workspace is retired.

• 1Freeze structure in the acquired workspace: no moves, renames or deletions until the merge is verified.
• 2Take a full export in the richest format the source offers, plus a second portable export such as HTML or Markdown files; restore any soft-deleted Confluence spaces you need first, and select attachments in the backup.
• 3Download each export as soon as its link arrives and copy it to storage the platform controls, since vendor download links expire.
• 4Export comments, page history and database contents separately wherever the standard export leaves them out.
• 5Download attachments and embedded files in bulk and compare counts with the source.
• 6Record permissions, restricted pages, private teamspaces and guest access in a manifest before anything moves.
• 7Pull HR, compensation, legal, board, security and client pages into a restricted holding area.
• 8Capture original authors and dates as page properties or a header line if the importer resets them.
• 9Build a redirect map from every old page ID or address to its new location, and update links in active runbooks and tickets.
• 10Migrate one representative space, compare it with the source, and fix the method before migrating the rest.
• 11Keep the source read-only until owners sign off, then archive the export with a provenance note.

How should confidential and client pages be handled?#

Confidential and client pages should be separated before the merge, because access controls in one tool do not reliably map to the other. A restricted Confluence page or a private Notion page can land in a company-wide space if the importer applies default permissions.

Client pages need their own treatment. Agencies, consultancies and software companies with services teams often keep client deliverables, configurations and meeting notes in the wiki. Those pages may be covered by client contracts and confidentiality terms, so they belong in a client-restricted area with the contract owner named, not in a general engineering space.

Personal pages and drafts are a smaller but real issue. Ask each author whether private drafts should move; by default, archive them without publishing them into the merged workspace.

Illustrative: a software holdco merging three wikis#

Illustrative: a fictional vertical software holdco, Quorvane Software Group, runs its platform company on Confluence Cloud. It acquires a scheduling product whose team documents everything in Notion, including an incident database related to its runbooks, and a billing product still on a self-managed Confluence instance.

The portfolio CTO freezes both acquired workspaces, exports them in full, and exports the Notion incident database as a table with relation keys. A test migration of the scheduling team's runbook space shows that page history and inline comments did not come across, so the full export becomes the system of record for history, and each migrated page carries a link to its archived version.

HR and customer implementation pages from both products move into restricted spaces before the merge. The billing product's self-managed instance stays read-only until owners sign off, then is retired. Engineers now search current runbooks in one place, and the archive keeps the history that explains them.

Why page history and comments matter after the merge#

Page history and comments matter because they record how a company actually works, which is what makes a knowledge base more than a pile of documents. A runbook revised after each incident, with comments explaining why a step changed, captures judgment that a clean final page does not.

That same record is what internal AI assistants and outside AI developers find useful. Under the SourceX Enterprise Data Value Framework, human-generated signal, domain expertise and recency raise value, while reproducibility lowers it: generic templates add little, but procedures shaped by real incidents are hard to reproduce. A merge that keeps only the latest version throws most of that signal away.

How SourceX reviews an archived knowledge base#

SourceX reviews an archived knowledge base through the SourceX five-step transaction, starting with metadata such as tools, spaces, date ranges and record types rather than page content. In the Rights step, client pages, vendor terms and confidential spaces are flagged; in Preparation, names and personal details are removed and pages are scanned for secrets such as passwords and API keys.

Each acquired entity approves its own release, and the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for the archive as delivered.