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. To be precise, a Confluence-to-SharePoint project involves three distinct types of work that are often conflated:

• Content migration — copying page text, attachments, and metadata from one system to another.
• Content model translation — rewriting Confluence's XHTML storage format into SharePoint's JSON-based CanvasContent1 web part model. This is a format rewrite, not a copy.
• Information architecture migration — restructuring Confluence spaces, page trees, and permission schemes into SharePoint site collections, hub sites, and M365 groups. This is a redesign.

Most failed migrations treat all three as a single step. They are not. The content model translation and information architecture migration require deliberate design decisions before you move a single page.

If you're planning a Confluence to SharePoint move from a 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. 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. For current per-user pricing, refer to the Microsoft 365 pricing page directly, as list prices change.

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 — see Jira integration handling section below
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.

Permission mapping reference

The table below maps Confluence DC permission types to their SharePoint structural equivalents. This is a structural mapping — it reflects where permissions should live in SharePoint, not necessarily a one-to-one feature match.

Confluence Permission Type	Scope	SharePoint Structural Equivalent
Global permission (can use Confluence)	Instance-wide	M365 tenant license assignment
Space permission — View	Space	Site member / visitor role on the communication site
Space permission — Add/Edit pages	Space	Site member (Contribute)
Space permission — Administer space	Space	Site owner
Space permission — restricted to group	Space	M365 security group assigned to site role
Page restriction — View only	Single page	Unique item-level permission (break inheritance) — use sparingly
Page restriction — Edit only	Single page	Unique item-level permission with read-only for others
Anonymous access	Space or page	SharePoint external sharing settings + site-level anonymous link

Key constraint: SharePoint's recommended limit is 5,000 unique permission scopes per list or library. If your Confluence instance has more than a few hundred pages with individual page restrictions, map those spaces to separate site collections rather than replicating restrictions page-by-page.

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

User mapping: Confluence DC accounts to Entra ID

Confluence Data Center user accounts are not automatically equivalent to Entra ID (Azure AD) user principal names (UPNs). In most enterprise DC environments, users authenticate via LDAP or Active Directory, but the Confluence username, display name, and email may differ from what's registered in Entra ID — especially if the organization has undergone domain changes, mergers, or email rebranding.

This matters for two reasons: authorship attribution and permission assignment.

• Authorship — SharePoint page metadata records who created and last modified each page. If the Confluence author identity doesn't resolve to a valid Entra ID UPN, pages either get attributed to the migration service account or fail to set the author field entirely. In either case, the page history looks wrong.
• Permission assignment — If space permissions reference Confluence groups backed by LDAP, you need to verify that those groups exist in Entra ID with the correct membership before the migration runs. A group that exists in Confluence but not in Entra ID produces a silent permission failure — the page migrates, but nobody can access it except site owners.

The standard resolution pattern:

1. Export Confluence's user directory (user key, username, display name, email).
2. Cross-reference against your Entra ID user list, matching on email or UPN.
3. Build a mapping table: confluence_user_key → entra_upn.
4. Feed that mapping into your migration pipeline so page author fields and permission assignments use the correct Entra identity.
5. Flag unresolved accounts (departed employees, service accounts, shared inboxes) for manual review before migration runs.

Unresolved user mappings are one of the most common causes of post-migration permission complaints. Handle this before wave one.

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.

Confluence Data Center runs on your infrastructure, which means you have options that Confluence Cloud doesn't offer: direct database access to the Confluence PostgreSQL or SQL Server backend. This lets you extract page content, version history, and user data without hitting API rate limits. It also means you can extract data that the REST API doesn't expose cleanly — including full page version history, plugin-stored macro data, and internal page metadata fields.

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.

Handling Jira-Linked Confluence Pages

In enterprise DC environments, Confluence and Jira are almost always tightly integrated. The Jira macro — which embeds live Jira issue lists, sprint boards, and individual ticket data directly into Confluence pages — has no SharePoint equivalent. The macro table above marks it as fidelity ❌ None. But "remove it" is not a complete answer for pages where Jira-embedded content is the primary reason the page exists.

Before migration, audit your Jira macro usage:

1. Identify pages that are primarily Jira views. A Confluence page that exists solely to display a Jira filter result or sprint backlog is not a knowledge base page — it's a Jira report. These pages do not belong in SharePoint at all. Archive them or link to the equivalent Jira board/filter directly.
2. Identify pages with Jira links embedded in narrative. A page that describes a feature spec and links to a handful of Jira tickets is a knowledge page with Jira references. Migrate the page; replace Jira macros with plain hyperlinks to the relevant Jira issues or epics.
3. Identify Confluence pages linked from Jira tickets. Jira tickets frequently reference Confluence pages by URL. After migration, those links break unless you set up redirects. The redirect table described in the coexistence section is the mechanism — ensure every Confluence page that's referenced from Jira has a working redirect to its SharePoint equivalent.
4. Communicate with the Jira team. If your organization is keeping Jira post-migration, the Jira team needs to know that Confluence page links are changing. Update Jira project documentation and wiki-linked tickets after each migration wave.

The Jira integration question is not a migration tool problem — it's a content strategy decision that needs to be made before wave one.

Version History Handling

Confluence DC maintains a full page version history — every edit is stored with its author, timestamp, and content diff. SharePoint also has versioning, but the two systems do not share a version format, and no current migration tool transfers Confluence version history into SharePoint as live, browsable versions.

In practice, the options are:

• Migrate the current version only. This is what WikiTraccs and most custom pipelines do by default. The page arrives in SharePoint as a single version. All prior Confluence history is not accessible in SharePoint.
• Archive version history as a separate document. For high-compliance or high-audit requirements, export the Confluence page history to a structured format (PDF, HTML, or JSON) and store it in a SharePoint document library alongside the migrated page. It won't be browsable in the SharePoint version UI, but the record is preserved.
• Retain Confluence DC for historical access. If full version history access is a hard compliance requirement, consider keeping the Confluence DC instance running in read-only mode post-migration specifically to serve historical version queries. This adds infrastructure cost but avoids the engineering effort of custom history archiving.

Decide on the version history approach before migration starts. It affects your storage planning, your compliance sign-off, and whether you can fully decommission the DC instance after cutover.

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.

Rollback procedure

A phased migration implicitly assumes you can roll back a wave if it goes wrong. Define this procedure before you start, not after a problem appears.

For each wave, rollback means:

1. Freeze write access to the SharePoint site for the affected wave — prevent any new content from being created in the migrated SharePoint site.
2. Re-enable write access on the Confluence space. If the space was set to read-only for the freeze, restore write permissions so users can continue working in Confluence.
3. Identify the delta — pull the list of Confluence pages that were edited after the wave's freeze date. These are pages whose SharePoint version may be stale.
4. Re-point redirects. If you deployed Confluence-side redirect notices pointing to SharePoint, remove them for the affected space so users land back on the live Confluence page.
5. Log the failure mode before retrying. Rollback is not a clean slate — you need to understand what went wrong (macro failure, permission error, path truncation) before running the wave again.

The redirect table (with confluence_page_id as the key) is what makes rollback tractable. Without it, re-pointing redirects at scale is a manual emergency.

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.

What Separates a Good Migration from a Failed One

A Confluence DC to SharePoint migration involves three distinct layers: copying content, rewriting the content model, and redesigning the information architecture. Treating them as a single step is the most common failure pattern.

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, ignore version history and user mapping until post-cutover complaints surface, and skip search QA until users complain.

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