Confluence Data Center to SharePoint Migration: Enterprise Guide

There is no native migration path from Confluence Data Center to SharePoint Online. Microsoft's SharePoint Migration Tool (SPMT) does not support Confluence as a source. Atlassian offers no export wizard targeting SharePoint. Every viable method requires third-party tooling, custom API scripts, or a managed migration service.

This is not a lift-and-shift. It is a content-model rewrite, a permission redesign, and an information-architecture project. Confluence stores page content as proprietary XHTML. SharePoint modern pages use a JSON-based content model built on sections, columns, and web parts. Every serious migration has to translate between these formats while also remapping permissions, metadata, links, and search behavior.

If you're running a Confluence DC instance with tens of thousands of pages and your organization already pays for Microsoft 365, this guide covers the hard platform limits, content translation challenges, permission mapping decisions, and tool options you need to evaluate before committing to a migration plan.

For the general Confluence-to-SharePoint direction (including Cloud), see our detailed Confluence to SharePoint Migration: Methods, Limits & Macro Mapping.

Why Enterprises Consolidate Confluence Data Center into SharePoint

The enterprise moving from Confluence DC to SharePoint is almost never evaluating Confluence Cloud. The whole point is to leave Atlassian.

The business case is straightforward: both E3 and E5 include the full Microsoft 365 productivity suite — all Office apps, Exchange Online, SharePoint, Teams, and OneDrive are identical across both licenses. Microsoft 365 E3 at approximately $36 per user per month is the enterprise workhorse. If you're already paying for M365 E3 or E5 licensing, SharePoint Online is included. The incremental cost of using SharePoint for wiki and knowledge base content is effectively zero.

Compare that to Confluence Cloud, which requires separate per-user Atlassian licensing on top of the M365 spend you're already committed to. For a 2,000-user enterprise, that's a meaningful line item to justify when you already have a capable platform sitting in your tenant.

That does not mean SharePoint is a perfect Confluence replacement. It means the enterprise is accepting a trade: weaker wiki-native behavior in exchange for platform consolidation, existing licensing, and tighter alignment with the Microsoft stack. If your knowledge base depends heavily on Confluence macros, deep page trees, and page-level restrictions, the migration work is in the translation layer, not in the copy step.

The other drivers we see repeatedly:

• IT governance consolidation — One vendor, one identity provider (Entra ID), one compliance stack (Microsoft Purview). No Atlassian-to-AD sync to maintain. Security teams manage DLP, retention policies, and eDiscovery through a single pane of glass.
• Existing SharePoint investment — Most DC-to-SharePoint buyers already have SharePoint sites for document management, project portals, or intranet. Adding wiki content extends what's already there.
• Atlassian Data Center end-of-sale pressure — With Atlassian's Data Center end-of-sale timeline creating licensing uncertainty, organizations want off the platform entirely rather than paying escalating DC renewal costs. For context, see our Atlassian Data Center End of Life 2029 guide.

For a broader look at enterprise IT governance and Microsoft consolidation timelines, see our Microsoft 2026 End-of-Support Timeline: The Definitive Migration Guide.

SharePoint Online Limits That Break Large Confluence Migrations

SharePoint Online has hard limits that directly impact how you architect a large migration. Ignoring them leads to silent failures — pages that won't create, paths that truncate, or libraries that choke the sync client.

The 400-character file path limit

The entire decoded file path, including the file name, can't contain more than 400 characters for OneDrive for home, OneDrive for work or school and SharePoint in Microsoft 365. This counts the site name, document library, folders, and file name — but not the tenant domain (e.g., tenant.sharepoint.com).

Confluence pages with long titles nested several levels deep hit this fast. A page titled "Q3 2024 Product Requirements — Engineering Review and Stakeholder Sign-Off" inside a deeply nested space structure can blow past 400 characters once SharePoint adds /sites/SiteName/SitePages/Parent/Child/ to the path.

Mitigation: Run a pre-migration scan of your Confluence page tree, calculate projected SharePoint paths, and truncate or hash page titles that exceed the limit. Do this before you move a single page.

The 30 million item ceiling and 300K sync threshold

A list can have up to 30 million items and a library can have up to 30 million files and folders. That's the hard ceiling. But the practical limit is much lower.

For optimum performance, Microsoft recommends syncing no more than 300,000 files in a single OneDrive or team site library. The same performance issues can occur if you have 300,000 items or more across all libraries you're syncing, even if you aren't syncing all items in those libraries.

A Confluence DC instance with 100K+ pages — each page becoming a SharePoint page plus its attachments — can easily exceed 300K items in a single site. Plan to split across multiple site collections.

The 5,000 list view threshold

You can store up to 30 million items or files in a list or library. But when a list view shows more than 5,000 items, you might run into a list view threshold error. Your migrated Site Pages library needs indexed columns and filtered views from day one. This is a separate limit from the sync threshold and catches teams off guard when they try to browse large page libraries.

Unique permissions cap

The supported limit of unique permissions for items in a list or library is 50,000. However, the recommended general limit is 5,000. If your Confluence DC instance has granular page-level restrictions across thousands of pages, you'll hit this fast. The permission section below covers the architectural implications.

How to plan the site collection split

For a DC instance with 100K+ pages across dozens of spaces:

1. Map spaces to sites — Each Confluence space becomes a separate SharePoint communication site. Related spaces get grouped under a hub site.
2. Calculate item counts — Each page generates at minimum one item (the .aspx page). Add attachments. A space with 5,000 pages and an average of 3 attachments per page = 20,000 items.
3. Split by security boundary first — Spaces with restricted access become separate site collections with their own permission boundaries. Then split by ownership, then by retention and attachment volume. If a space has different owners, different sensitivity rules, or a history of page restrictions, it probably deserves its own site.
4. Archive inactive content — Spaces untouched for 2+ years may not need to be migrated as live pages. Consider an HTML/PDF archive instead.

For detailed hub site architecture guidance, see The Modern SharePoint Architecture 2026: Transitioning from Subsites to Hub Sites.

Content Format Translation: Confluence XHTML to SharePoint Modern Pages

This is where migrations get technically painful. Confluence stores page content as XHTML storage format. SharePoint modern pages use a JSON-based content model (CanvasContent1) built on web parts arranged in sections and columns. There is no shared format between them. You cannot simply copy text — you must parse the XML and generate valid SharePoint JSON.

Confluence Element	SharePoint Equivalent	Fidelity	Notes
Headings, paragraphs, lists	Text web part	✅ High	Translates cleanly
Basic tables	Text web part (inline table)	⚠️ Medium	SharePoint's table formatting is more constrained — merged cells and colored rows often break
Inline images	Image web part / inline in text	⚠️ Medium	Images must be uploaded to Site Assets first, then referenced in the JSON payload
Code blocks (code macro)	Code Snippet web part	⚠️ Medium	Fewer syntax highlighting options. Code Snippet is not listed among supported web parts for automated Graph API page creation — API-driven migrations may need <pre><code> inside a Text web part
Table of Contents macro	Table of Contents web part	✅ High	Near-equivalent exists
Children Display macro	No equivalent	❌ Low	Must be converted to a static link list or removed
Expand/Collapse macro	No equivalent	❌ Low	Content is flattened or placed in a separate section
Jira macro	No equivalent	❌ None	Must be replaced with a link to the Jira instance or removed
draw.io diagrams	Image web part	⚠️ Medium	Exported as static images — interactivity is lost
Embedded Office docs	File Viewer web part	✅ High	SharePoint natively renders Word, Excel, and PowerPoint files well
Page properties / metadata	Managed metadata or page properties	⚠️ Medium	Requires explicit mapping
Status macros (lozenges)	No equivalent	❌ Low	Must be converted to styled text or HTML tables
Content by Label macro	Highlighted Content web part	⚠️ Medium	Approximate equivalent exists but requires managed metadata setup

Most Confluence macros have no direct SharePoint equivalent because SharePoint uses web parts that cannot be nested. Tools like WikiTraccs apply hundreds of transformation rules — converting Code Block macros to Code Snippet web parts, Children Display to static link lists, and draw.io diagrams to images. Macros without a mapping become text placeholders.

If a space depends on macros for navigation or dynamic rollups (TOC, children trees, label rollups, draw.io), you are rebuilding behavior, not just formatting. Treat those spaces as application migrations, not content copies.

A practical mapping strategy that works:

1. Move page narrative into modern pages.
2. Move files into document libraries.
3. Replace macro behavior with navigation, metadata, or custom web parts only when the business case justifies it.
4. Archive low-value pages instead of rebuilding them.

For a deeper dive on macro mapping rules, see Confluence to SharePoint Migration: Methods, Limits & Macro Mapping.

The Permission and Metadata Problem

Permission model mismatch

Confluence Data Center permissions span global permissions, space permissions, and page restrictions. Space permissions are additive, and page-level view restrictions are inherited by child pages. SharePoint uses a fundamentally different model: permissions flow down from the site collection through subsites to libraries and individual items, and breaking inheritance is an explicit action with real performance cost.

The key architectural decisions:

• Sensitive spaces need separate site collections. If a Confluence space has access restricted to a specific AD group, the cleanest SharePoint mapping is a dedicated communication site with that M365 group as site members. Trying to enforce this with unique permissions on individual pages within a shared site collection will hit the 50,000 unique permission scope limit (recommended 5,000) and degrade performance.
• Map Confluence groups to M365 groups. If your DC instance uses LDAP/AD groups for space permissions, create corresponding M365 security groups or use your existing Entra ID groups. This is the cleanest path.
• Page-level restrictions are expensive in SharePoint. When a list, library, or folder contains more than 100,000 items, you can't break permissions inheritance on the list, library, or folder. If your Confluence instance relies heavily on page-level restrictions, you need to decide: replicate them and accept the performance hit, or restructure into separate site collections.
• Don't recreate a dense forest of Confluence page restrictions as unique ACLs on individual SharePoint pages. The cost is not just hitting the 50,000 scope limit — search will fail to index the library correctly, and views will break before you reach the theoretical maximum.

For a full treatment of SharePoint permission architecture, see The Definitive Guide to SharePoint Permissions & Security.

Metadata: where migrations quietly lose organizational context

Confluence page metadata — labels, custom metadata from plugins like Comala, Scroll Versions, or custom user macros — doesn't map automatically to anything in SharePoint. This is not page chrome; it's the structure that makes the wiki findable. Many enterprise migrations lose this context because the translation is manual and tedious.

The mapping pattern:

• Confluence labels → SharePoint managed metadata term sets or enterprise keywords. This preserves the taxonomy but requires creating the term set structure in advance.
• Space key / legacy source ID → hidden or admin-facing page property, useful for redirect mapping and rollback.
• Page category / KB type / policy type → page property or content-type field.
• Plugin-defined taxonomy → managed metadata if controlled, plain property if one-off.
• Page ancestry (parent/child tree) → SharePoint page tree (navigation) or metadata columns that capture the hierarchy.
• Restricted space marker → separate site architecture, not a tag.

Search only becomes useful when those source fields are mapped into crawled and managed properties that Microsoft Search can index. If you create or change properties, SharePoint has to re-crawl before those values appear in results. Automating the metadata mapping requires extraction scripts that understand both the Confluence storage schema and your target SharePoint information architecture.

For metadata strategy guidance, see Mastering SharePoint Information Architecture 2026.

Migration Methods: SPMT, Third-Party Tools, and Custom APIs

There is no magic button. The right method depends on whether you need editable modern pages, preserved authorship, intact links, and working navigation after cutover.

Method	Reality	Best use case	Main failure mode
SPMT	Does not support Confluence as a source	None for Confluence	Only handles SharePoint Server and file-based sources
WikiTraccs	Purpose-built Confluence-to-SharePoint tool with hundreds of transformation rules	Self-service migrations where team can manage architecture and QA	Macro fidelity edge cases, permissions, and site architecture still need design work
ShareGate / AvePoint	Strong M365 migration tools, no native Confluence page translation	Adjacent M365 cleanup or staged content already in a supported format	Requires intermediary export that destroys macros and structure
Custom API pipeline	Highest control, highest engineering cost	Large DC estates, custom metadata, strict cutover requirements	Graph throttling, transformation QA burden, link rewriting
HTML / Word / PDF export	Fastest low-fidelity archive path	Cold historical spaces you don't need as editable modern pages	Loses editable structure, wiki behavior, and page-level search

SharePoint Migration Tool (SPMT): Not applicable

The SharePoint Migration Tool (SPMT) is a free and easy to use migration solution to help you migrate content from on-premises SharePoint sites to Microsoft 365. Migrating data from SharePoint to SharePoint, OneDrive, and Teams is possible with the SPMT tool. However, it doesn't support any other source to migrate data.

SPMT is irrelevant for Confluence migrations. Don't waste time evaluating it.

WikiTraccs: The dedicated Confluence-to-SharePoint tool

WikiTraccs makes migrating content from Atlassian Confluence to SharePoint Online easier. It contains hundreds of transformation rules for a wide range of Confluence formattings, structures and macros.

It supports both Confluence Cloud and Data Center, outputs SharePoint Online modern pages, and handles link rewriting, attachment migration, and user mapping. The largest successful WikiTraccs-based migration "in the wild" consisted of ~160 spaces and ~200,000 pages.

WikiTraccs is the strongest self-service option if your team has the capacity to manage the migration. It handles the XHTML-to-web-part transformation, rewrites internal links, and migrates attachments. Where it falls short: it's a tool, not a service. You still need to plan the architecture, handle edge cases, and validate results.

ShareGate and AvePoint: Limited Confluence support

ShareGate is a migration tool specifically designed for SharePoint and Office 365 environments. It is widely recognized as a popular and reliable solution for managing and executing SharePoint migrations.

Neither ShareGate nor AvePoint natively supports Confluence DC as a direct source. They excel at SharePoint-to-SharePoint scenarios. To use them for a Confluence migration, you'd need to first export Confluence content to an intermediary format (HTML, Word) and then import — which destroys macro functionality, flattens tables, and frequently loses inline image placement.

Custom API pipeline

The fully custom approach: extract from Confluence via its REST API (or direct database access for DC), transform the XHTML to SharePoint's CanvasContent1 JSON format, and ingest via the Microsoft Graph API or SharePoint REST API.

This gives maximum control but comes with serious challenges:

• Graph API throttling — Microsoft imposes per-app-per-tenant throttling limits measured in resource units. Limits vary based on the number of licenses purchased, and create/update/delete operations cost more resource units than reads. When you exceed your quota, Microsoft returns HTTP 429 or 503 responses. Custom scripts must implement exponential backoff and honor Retry-After headers. One-threaded scripts that look fine in a pilot stall in production against a 100K+ page estate.
• Content transformation complexity — Building a reliable XHTML-to-CanvasContent1 converter is a significant engineering effort. Every Confluence macro needs a mapping rule, and Graph page creation only supports a limited set of web parts.
• Link rewriting — Every internal Confluence link (/display/SPACE/Page+Title) must be rewritten to the new SharePoint URL (/sites/SiteName/SitePages/Page-Title.aspx). Missing even a small percentage creates a broken link epidemic.

Export-to-HTML/Word: The archival path

For archival migrations where you don't need live, editable SharePoint pages: export Confluence spaces to HTML or PDF, upload to a SharePoint document library as files. This is fast and preserves content for reference, but the content isn't searchable as page text and loses all wiki structure. It's often the right answer for stale project spaces nobody wants to actively maintain after the move.

If you need detail on extraction methods, see How to Export All Data from Confluence: Methods, Limits & Tools.

Coexistence and Phased Migration Strategy

A large DC-to-SharePoint migration is never a weekend cutover. Expect weeks to months for a 100K+ page instance.

The phased approach

1. Start with the hardest spaces, not the easiest. Spaces with heavy macros, large attachments, page restrictions, and high-value search traffic expose issues early. Fix problems before tackling the high-volume, lower-complexity spaces.
2. Set a freeze date per wave. Communicate a clear cutoff for each batch. On this date, the target Confluence space is set to read-only. Run a delta sync to capture any final edits made before the freeze.
3. Validate before switchover. Check permissions, links, metadata, and search in SharePoint for each wave. Don't move on until the migrated content is verified with the department heads who own that content.
4. Switch authoring to SharePoint. Once a space is validated, all new content creation moves to SharePoint. Confluence stays online for coexistence and redirects.
5. Run delta syncs. Content edited between the initial migration and the freeze date needs a delta pass. Plan for this explicitly in your timeline — it's not optional.

Redirect management

Broken links are the #1 post-migration complaint. Users have Confluence URLs bookmarked, embedded in Jira tickets, Slack messages, emails, and other wikis.

• Confluence-side redirects — After each space is migrated, replace the original Confluence pages with redirect notices pointing to the new SharePoint location. This prevents users from editing stale content.
• DNS/reverse proxy redirects — If you're decommissioning the DC server, set up URL redirects from the old Confluence domain to SharePoint. Because Confluence DC runs on your infrastructure, you can configure your reverse proxy (Nginx, Apache, or IIS) to route requests from old Confluence URLs to new SharePoint page URLs.
• Mapping table as source of truth — Confluence's pageId is the stable source identifier. Even if page titles change, the pageId stays the same. Use it as the key in your redirect registry.

Post-Migration Search and Discoverability

One of Confluence DC's strengths is unified search across all spaces. After migration, content is indexed by Microsoft Search — but the transition is not instant, and sloppy permission mapping will make content invisible.

Indexing delays

SharePoint Online uses a continuous crawl model instead of scheduled full crawls. For a very large migration (e.g., 6 million items), it can take from 24 hours up to several days for the entire set of items to be fully indexed.

SharePoint Online uses an automated schedule that can't be changed. This schedule is managed by Microsoft, and generally takes between 15 minutes and an hour between upload and availability for search results. That's for individual items — a bulk migration with hundreds of thousands of items takes much longer for the full index to catch up.

Plan for this:

• Communicate the delay — Set expectations that search will be incomplete for the first 48–72 hours after each migration wave. Content is successfully migrated; it just won't appear in search results immediately.
• Use targeted reindexing sparingly — You can request a reindex of a specific site via Site Settings, but reindexing a site can cause a massive load on the search system. Don't reindex your site unless you've made changes that require all items to be reindexed.

Configuring search verticals and managed properties

To replicate the Confluence search experience:

• Set up Microsoft Search verticals — Create custom search verticals in the Microsoft 365 admin center so users can scope searches to "Knowledge Base" or "Wiki" content specifically.
• Map managed properties — If you migrated Confluence labels as SharePoint managed metadata, ensure those properties are mapped as refinable managed properties in the search schema so users can filter by topic, department, or legacy Confluence labels.
• Test search explicitly — Test old page titles, acronyms, label-driven queries, known restricted pages, and deep content that used to be found through Confluence macros. SharePoint search results are security-trimmed, meaning bad permission mappings look exactly like missing content. Don't sign off the migration just because pages load in a browser. Sign off when users can find them.

How ClonePartner Handles Confluence DC to SharePoint Migrations

We've executed enough Confluence-to-SharePoint migrations to know exactly where the standard tools fall short. Our approach covers the gaps:

• Custom Confluence DC extraction — Direct REST API and database-level extraction from your DC instance, pulling pages, attachments, metadata, labels, and permission schemes.
• Content transformation pipeline — Proprietary XHTML-to-CanvasContent1 conversion with macro-to-web-part mapping rules built from real migration experience. No flattening to Word documents. No data loss on supported macros.
• Managed metadata mapping — Confluence labels, plugin metadata, and page properties are mapped to SharePoint term sets and site columns before migration, not after.
• Permission scheme translation — Automated mapping from Confluence LDAP/AD groups to M365 groups, with architectural recommendations for spaces that need separate site collections. We stay within SharePoint's 5,000 unique permission threshold to keep your environment performant.
• Phased migration orchestration — Space-by-space migration with redirect management, delta sync passes, and freeze-date coordination.
• Post-migration search validation — We verify that migrated content is indexed and discoverable in Microsoft Search before sign-off.

What Separates a Good Migration from a Failed One

A Confluence DC to SharePoint migration is fundamentally a content transformation project, not a file copy. The XHTML-to-web-part conversion, the permission model mismatch, the 400-character path limit, and the API throttling constraints all compound at enterprise scale.

The organizations that execute this well share three traits: they plan the SharePoint information architecture before touching any migration tooling, they migrate in phases rather than attempting a big-bang cutover, and they validate search and link integrity after every wave.

The recurring failure patterns are just as consistent: teams underestimate macro behavior, overestimate how far page-level permissions can stretch in SharePoint, and skip search QA until users complain.

If you remember one thing, make it this: Confluence Data Center to SharePoint is a redesign project disguised as a migration project. Plan for that reality on day one and the cutover gets much less painful.

If you're evaluating this migration and want a technical assessment of your Confluence DC instance — including page counts, macro usage analysis, and a recommended site collection architecture — talk to our team.