The push to leave Confluence almost never starts with the people who use it every day. It starts in a budget review, when someone notices the company is paying Atlassian for a wiki while already paying Microsoft for a platform licensed to every employee. An executive mandate follows: consolidate onto Microsoft 365, retire the overlapping tools, and stop paying twice for collaboration.
That is the most common trigger we see at dataBridge, and it shapes everything about how these projects go. The mandate is made two levels above the teams who live in Confluence, it’s framed as a cost decision, and it usually arrives with a deadline attached. What it doesn’t arrive with is any acknowledgment that Confluence and SharePoint store knowledge in fundamentally different shapes – which means the project everyone budgeted as “copy the content over” is actually a restructuring project wearing a migration’s clothes.
This post is the playbook for closing that gap: why these migrations happen, what genuinely doesn’t transfer, where Confluence content should land in SharePoint, and how to run the move so the consolidation delivers what the mandate promised.
Why organizations migrate from Confluence to SharePoint
The honest answer is rarely “we dislike Confluence.” Confluence is a capable wiki. The drivers are structural:
- License overlap – Microsoft 365 is already paid for across the whole company, and leadership wants one collaboration stack, one security model, and one vendor bill
- IT and security consolidation – every additional platform is another identity boundary, another compliance review, another place data governance has to reach
- The Copilot effect – content sitting in Confluence lives outside the Microsoft 365 boundary, so Copilot can’t see it. As organizations invest in Copilot, every knowledge base outside M365 becomes invisible to the AI layer they’re paying for
- Acquisition and standardization – a merged or acquired business unit arrives on Atlassian, and the parent standardizes on Microsoft
Notice that none of these are content arguments. They’re platform arguments, made at the platform level. That’s legitimate – the savings and the simplification are real. But it means the people approving the project usually haven’t looked inside the Confluence spaces they’ve just scheduled for demolition, and the timeline reflects that.
Confluence and SharePoint store knowledge in different shapes
This is the part that breaks naive lift-and-shift plans, so it’s worth being precise.
In Confluence, everything is a page. Pages live in spaces, nest into deep page trees, and carry their attachments, comments, and labels with them. The hierarchy is the navigation. Macros embedded in pages generate dynamic content – child-page lists, Jira issue tables, status roll-ups – so a Confluence page is often part document, part application.
SharePoint separates those concerns. Sites contain modern pages, document libraries, and lists. Documents live in libraries with metadata, not as attachments hanging off a page. Navigation is built deliberately rather than inherited from a tree. Dynamic behavior comes from web parts, not macros. Structure comes from information architecture you design, not from wherever someone happened to nest a page in 2019.
Copy a ten-level Confluence page tree into SharePoint as-is and you get the worst of both worlds: a wiki’s sprawl without a wiki’s navigation, in a platform that expected you to make structural decisions you skipped. The migration only works if you treat the shape difference as the actual project.
What doesn’t move cleanly
Plan around these from day one, because each one surfaces late if you don’t:
- Macros – dynamic Confluence content has no automatic SharePoint equivalent. Jira tables, child-page listings, and include-macros either get rebuilt as web parts, replaced with static content, or dropped. This is usually the single biggest rework item
- Page hierarchy – deep page trees have to be flattened and re-expressed as site structure and navigation. A tree that “worked” in Confluence often turns out to be three good pages and forty stale ones
- Comments and page history – most tooling moves page content, not the conversation and revision trail around it. If the history matters for compliance, capture it deliberately
- Labels – Confluence labels can map to SharePoint metadata, but only if someone designs the mapping. Done well, this is an upgrade; ignored, the classification is simply lost
- Permissions – space-level permissions don’t translate one-to-one to SharePoint’s site and library model. Rebuild access intentionally rather than approximating
- Jira integration – if your teams live in Jira, decide up front how linked issues will surface after the move, because the deep integration doesn’t come with you
None of this makes the migration a bad idea. It makes “we’re just copying pages” a bad estimate.
Decide where content lands before you move anything
The single most useful planning exercise is mapping Confluence content types to their correct SharePoint destinations – because the answer is not one place.
- How-to articles, runbooks, and reference content belong in a structured SharePoint knowledge base, with metadata, ownership, and review dates
- Policies, announcements, and company-wide reference belong on intranet pages, written for consumption rather than collaboration
- Working documents and attachments belong in document libraries, not embedded on pages – this is where Confluence’s attachment model gets corrected rather than copied
- Active project and team spaces map to team sites, scoped to the group that owns them
- Stale content – and there will be a lot of it – gets archived or retired, not migrated
That last line is the position we’ll defend in any room: a Confluence migration is the best content audit opportunity your organization will ever get, and migrating everything wastes it. Every space you move wholesale carries its dead weight into the new platform and dilutes search, Copilot grounding, and user trust on day one. Move what’s alive. Archive what’s not. Your future self – and your AI tooling – will thank you.
The migration plan that actually works
The sequence matters more than the tooling. Third-party migration tools exist for Confluence-to-SharePoint moves and they help with bulk page conversion, but no tool makes the structural decisions for you. The plan:
- Inventory and measure. List every space, its owner, its page count, and its last-edit activity. Expect a substantial share of pages untouched for over a year – that number becomes your scope-reduction argument
- Map destinations and owners. Every space gets a verdict: knowledge base, intranet, team site, library, or archive. No space moves without a named owner on the receiving end
- Pilot one real space. Pick a space that matters, move it end to end – structure, macros, permissions, navigation – and let its team work in it. The pilot exposes your rework rate, which makes the rest of the estimate honest
- Migrate in waves, rebuilding where the shapes differ. Pages that are really documents become library content with metadata. Trees become navigation. Macro-driven pages get rebuilt or consciously simplified
- Redirect and retire. Run Confluence read-only for a defined window, redirect the high-traffic URLs, then turn it off on schedule. A consolidation that leaves the old platform running indefinitely saved nothing
If you want a structured look at whether your environment and your content are ready before committing to dates, that’s exactly what our migration readiness assessment exists to answer.
Take the scope gap to leadership early
One more thing, and it decides whether the project ends well. The executive mandate set a budget and a deadline based on a copy job. Your inventory will show a restructuring job. Take that gap to leadership early, with the numbers from step one – spaces, page counts, stale percentage, macro-heavy pages – and re-anchor the timeline before work starts rather than three weeks before cutover.
In our experience running SharePoint migrations, the consolidations that succeed aren’t the ones with the fewest surprises. They’re the ones where the surprises got surfaced while the schedule could still absorb them. The mandate gave you the why and the when. The inventory gives you the what. Leadership needs both in the same conversation.
FAQ
Is there a Microsoft tool to migrate Confluence to SharePoint?
No native Microsoft tool handles Confluence sources. Third-party migration tools can convert pages and attachments in bulk, and scripted approaches via both platforms’ APIs are common. Tooling accelerates the copy work, but macros, hierarchy, and permissions still require human decisions and rebuild effort.
Should we migrate everything from Confluence?
No. Inventory first, then move what’s current and owned. A large share of most Confluence instances is stale, and migrating it pollutes search and Copilot results in the new environment. The migration is your best opportunity to retire dead content with executive air cover.
Where should Confluence content go in SharePoint?
It depends on the content type, not the source structure. Reference and how-to content belongs in a knowledge base, company-wide material on intranet pages, working files in document libraries, and active team spaces in team sites. Mapping content types to destinations is the core planning step.
What happens to Confluence macros in SharePoint?
They don’t transfer. Dynamic content built on macros has to be rebuilt with SharePoint web parts, replaced with static equivalents, or consciously dropped. Counting macro-heavy pages during inventory is the fastest way to size the real rework effort.
How long does a Confluence to SharePoint migration take?
It scales with structure, not just page count. A handful of well-organized spaces can move in weeks; a large instance with deep trees, heavy macro use, and unclear ownership runs months. The pilot space is what turns the estimate from a guess into a forecast.
Reviewed By
