Confluence to SharePoint Migration: Methods, Limits & Macro Mapping

There is no native migration path from Confluence to SharePoint. Microsoft's SharePoint Migration Tool (SPMT) does not support Confluence as a source — SPMT is a migration solution to help you migrate content from on-premises SharePoint sites to Microsoft 365, and it supports migrating data from SharePoint to SharePoint, OneDrive, and Teams, but doesn't support any other source. There is no Atlassian-built migration wizard for this direction either. Moving from Confluence to SharePoint requires third-party tools, custom API scripts, or a migration partner.

This guide covers the real methods for migrating Confluence content to SharePoint Online, the hard platform constraints on both sides, and the macro-to-web-part mapping decisions that determine whether your migration succeeds or silently drops content.

For a deep dive on getting data out of Confluence before starting any migration, see How to Export All Data from Confluence: Methods, Limits & Tools.

Why Migrating from Confluence to SharePoint Is Complex

Confluence and SharePoint solve fundamentally different problems, and their data models reflect that.

Confluence is a collaborative wiki. Content lives in spaces, each containing a deep, nested tree of parent-child pages. Pages combine rich text, inline macros, embedded diagrams (draw.io, Gliffy), tables, and attachments — all stored in Atlassian's proprietary XHTML-based storage format. Hierarchy is first-class: every page knows its parent, and the page tree drives navigation.

SharePoint is a document management and intranet platform. Content lives in sites, each containing document libraries (for files), lists (structured data), and modern site pages (.aspx pages rendered via CanvasContent1 JSON). Confluence follows a hierarchical structure with pages and subpages automatically displayed in navigation, while SharePoint uses a different approach with a single-page repository and libraries for documents — its navigation tree starts with a few default links but is customizable.

This architectural mismatch creates several hard problems:

• Page hierarchy doesn't transfer. Confluence's parent-child tree has no native equivalent in SharePoint. You need a third-party solution like WikiPakk or custom SPFx navigation to replicate the page tree experience.
• Macros don't exist in SharePoint. Confluence macros (Code Block, Expand, Info/Warning panels, Children Display, Table of Contents) must be mapped to SharePoint web parts — or replaced entirely. In SharePoint Online, on modern SharePoint pages, you cannot nest web parts. This is a hard limitation that breaks any macro using nested content.
• Labels ≠ Metadata. Confluence uses freeform labels for categorization. SharePoint uses managed metadata term sets, content types, and enterprise keywords — a much more structured system.
• Permissions models differ. Confluence has space-level and page-level restrictions tied to Atlassian accounts. SharePoint uses Entra ID (formerly Azure AD), SharePoint groups, and a completely different inheritance model.
• Blog posts need explicit mapping. Confluence blog posts don't have a direct equivalent in SharePoint pages. SharePoint's sitePage model supports promotionKind values of page and newsPost, so blog-style content usually fits the news post model better than a standard page.
• Authorship and timestamps are read-only. In SharePoint's sitePage schema, createdBy, createdDateTime, lastModifiedBy, and lastModifiedDateTime are read-only fields. If preserving source authorship and dates matters for audit or search, you need custom columns (e.g., Source Author, Source Created) rather than assuming the API will let you stamp native page metadata.

For guidance on mapping Confluence spaces into modern SharePoint architecture, see The Modern SharePoint Architecture 2026: Transitioning from Subsites to Hub Sites.

Understanding Confluence Export Formats

Before choosing a migration method, understand what Confluence actually gives you when you extract content. There are three primary export paths, each with different trade-offs.

Confluence Storage Format (XHTML)

Every Confluence page is stored internally as XHTML — Atlassian's proprietary storage format. This is the canonical representation of all page content, including macros. When you retrieve a page's body via the REST API using expand=body.storage, you get raw XHTML like this:

<h2>Project Overview</h2>
<p>This project tracks the migration timeline.</p>
<ac:structured-macro ac:name="code">
  <ac:parameter ac:name="language">python</ac:parameter>
  <ac:plain-text-body><![CDATA[print("hello world")]]></ac:plain-text-body>
</ac:structured-macro>
<ac:structured-macro ac:name="info">
  <ac:rich-text-body>
    <p>This is an info panel with <strong>rich text</strong> inside.</p>
  </ac:rich-text-body>
</ac:structured-macro>
<ac:structured-macro ac:name="expand">
  <ac:parameter ac:name="title">Click to expand</ac:parameter>
  <ac:rich-text-body>
    <p>Hidden content here.</p>
  </ac:rich-text-body>
</ac:structured-macro>

Key characteristics:

• Standard HTML elements (<h2>, <p>, <table>) are used for basic content.
• Macros are represented as <ac:structured-macro> elements with ac:name identifying the macro type.
• Macro bodies use either <ac:plain-text-body> (code, noformat) or <ac:rich-text-body> (panels, expands, excerpts).
• Inline images reference attachments via <ac:image><ri:attachment ri:filename="screenshot.png" /></ac:image>.
• Internal links use <ac:link><ri:page ri:content-title="Target Page" ri:space-key="PROJ" /></ac:link>.

This is the format your migration scripts need to parse and transform. Every method — custom scripts, WikiTraccs, or managed migration — starts from this storage format.

XML Site Export

Confluence's space-level XML export produces a zip containing an entities.xml file with all pages, comments, attachments metadata, and space configuration. You can export all or part of a Confluence space to various formats, including Microsoft Word, HTML, PDF and XML. To use the space export functionality, you need the 'Export Space' permission.

The XML export is designed for re-importing into another Confluence instance. Its schema is Confluence-specific — page bodies are embedded as CDATA blocks in the same XHTML storage format described above. Attachments are included as binary files in the zip.

The XML export can be useful as a bulk extraction mechanism when API rate limits are a constraint, because you get all pages in a single download. The trade-off is that you still need to parse the Confluence-specific XML wrapper to extract the XHTML bodies, and the export can time out on large spaces. Massive spaces frequently time out during HTML or PDF generation. Atlassian says a typical export of around 100 pages should generally complete within a few minutes.

REST API Extraction

The Confluence REST API gives programmatic access to every page, attachment, comment, and space. This is the most flexible extraction method and the one used by custom scripts and most third-party tools.

Key endpoints for migration:

• GET /wiki/rest/api/content?spaceKey=PROJ&type=page&expand=body.storage,version,ancestors,metadata.labels — retrieves pages with their storage-format body, version info, parent chain, and labels.
• GET /wiki/rest/api/content?spaceKey=PROJ&type=blogpost — retrieves blog posts separately from pages.
• GET /wiki/rest/api/content/{id}/child/attachment — lists attachments for a specific page.
• CQL search: GET /wiki/rest/api/content/search?cql=space=PROJ AND type=page — flexible querying with Confluence Query Language.

Pagination is mandatory. The API returns a maximum of limit results per call (default 25, max typically 100 for body expansions). Use the _links.next URL in each response to iterate through all results. Do not assume a high limit value returns all records — CQL search with expand=body.storage.value can cap results well below the requested limit.

For Confluence Cloud, all API calls require authentication via API token (basic auth with email + token) or OAuth 2.0. For Data Center, basic auth or personal access tokens work.

Transforming Confluence XHTML into SharePoint Pages

The core technical challenge in any Confluence-to-SharePoint migration is transforming Confluence's XHTML storage format into SharePoint's CanvasContent1 JSON. This section explains what CanvasContent1 looks like, how the mapping works, and where it breaks down.

SharePoint's CanvasContent1 Structure

Every SharePoint modern page stores its body content in a single field called CanvasContent1. This field contains a JSON array of "controls" — each control represents a web part or a text block within a section/column layout.

A simplified example of a modern page with a heading, paragraph, and code snippet:

[
  {
    "position": {
      "zoneIndex": 1,
      "sectionIndex": 1,
      "sectionFactor": 12,
      "controlIndex": 1
    },
    "controlType": 4,
    "innerHTML": "<h2>Project Overview</h2><p>This project tracks the migration timeline.</p>"
  },
  {
    "position": {
      "zoneIndex": 1,
      "sectionIndex": 1,
      "sectionFactor": 12,
      "controlIndex": 2
    },
    "controlType": 3,
    "webPartId": "7b317fca-3a86-4c0f-9b12-b26f5d3b1b42",
    "webPartData": {
      "dataVersion": "1.0",
      "properties": {
        "language": "python",
        "code": "print(\"hello world\")"
      }
    }
  }
]

Key concepts:

• controlType: 4 = Rich text (RTE) block. The innerHTML field accepts a subset of HTML.
• controlType: 3 = Web part. Identified by webPartId (a GUID), with configuration in webPartData.properties.
• sectionFactor controls column width. 12 = full width, 8 + 4 = two-column layout (2/3 + 1/3), 6 + 6 = equal two-column.
• zoneIndex and sectionIndex control vertical ordering of sections.
• The total size of CanvasContent1 cannot exceed ~2 MB.

The Transformation: Storage Format → CanvasContent1

Here is how the Confluence XHTML example from the previous section maps to CanvasContent1:

The transformation logic for a custom migration script follows this general pattern:

1. Parse the XHTML storage format using an XML/HTML parser.
2. Walk the DOM tree node by node.
3. For each standard HTML node (<h1>–<h6>, <p>, <table>, <ul>, <ol>): accumulate into a controlType: 4 (RTE) block.
4. For each <ac:structured-macro>: look up the macro name in your mapping table. If it maps to a web part (e.g., Code Block → Code Snippet), emit a controlType: 3 block with the correct webPartId and extract parameters. If it maps to a snapshot, render the body content as static HTML in a controlType: 4 block.
5. For each <ac:image>: resolve the ri:filename against the page's attachment list, construct the Site Assets URL, and emit an Image web part or inline <img> tag.
6. For each <ac:link>: look up the target page in your URL mapping table and emit a standard <a> tag with the SharePoint URL.
7. Wrap all controls in the section/column structure based on Confluence's page layout (<ac:layout> elements map to sectionFactor values).

Modern Pages vs. Classical Pages

This guide focuses on SharePoint modern pages because they are Microsoft's current standard and the target for most migrations. However, classical pages (wiki pages and publishing pages) still exist in on-premises SharePoint 2019 and hybrid environments.

Key differences for migration:

• Modern pages use CanvasContent1 JSON, support web parts, and render in the modern SharePoint experience.
• Classical wiki pages store content as raw HTML in the page's .aspx file. You can place Confluence-exported HTML more directly into classical pages, but you lose access to modern web parts, modern search integration, and the responsive page framework.
• Classical publishing pages use page layouts with field controls. Content must be slotted into predefined fields — a different transformation than either modern or wiki pages.

If your target is SharePoint Online, use modern pages. Classical pages are only relevant for on-premises SharePoint 2019 or SharePoint Server Subscription Edition deployments where modern page support is limited or where publishing site infrastructure already exists.

SPFx Web Parts for Missing Functionality

When a Confluence macro has no native SharePoint web part equivalent, a custom SharePoint Framework (SPFx) web part can fill the gap. Common scenarios:

• Page tree navigation — WikiPakk provides this as a commercial SPFx solution; building a custom one requires the SPFx Yeoman generator, React, and the SharePoint REST/Graph API to query site pages and render a tree.
• Table of Contents — The PnP Page Navigator is an open-source SPFx web part that reads heading elements from the current page and renders a navigable TOC.
• Children Display — A custom SPFx web part can query the site pages library for pages matching a metadata filter or naming convention and render a dynamic list.

SPFx web parts are deployed as .sppkg packages to the tenant app catalog. They run client-side in the browser and have access to the Microsoft Graph and SharePoint REST APIs. For migration purposes, the decision to build custom SPFx is a cost/benefit trade-off: it restores interactivity that snapshots lose, but adds development and maintenance overhead.

The 4 Methods for Confluence to SharePoint Migration

Method 1: Manual Export and Re-upload

The lowest-tech approach. You can export all or part of a Confluence space to various formats, including Microsoft Word, HTML, PDF and XML. To use the space export functionality, you need the 'Export Space' permission.

How it works:

1. Export individual pages as Word/PDF, or export an entire space as HTML or XML.
2. Upload the exported files to a SharePoint document library.
3. Optionally, convert HTML files to .aspx pages for display as SharePoint site pages.

What breaks:

• Only the first 50 images attached to the page are exported to your Word document. This is to prevent out of memory errors affecting your whole Confluence site. If your pages are image-heavy, the Word path silently drops content.
• Confluence space-level PDF and HTML exports exclude blog posts.
• You will lose page links, navigation, labels and many other types of essential content.
• XML export is designed for re-importing into another Confluence instance, not SharePoint.

Best for: Archiving small spaces (<50 pages) where formatting fidelity doesn't matter. Not a migration strategy.

Method 2: HTML Export → ASPX Conversion

Export all content from Confluence as HTML files. Because of compatibility issues, if you don't convert to HTML, you are likely to lose some information during the migration. Convert all HTML files to ASPX files.

How it works:

1. Export the space as HTML (zip).
2. Rename .html files to .aspx.
3. Enable custom scripts at the tenant and site level. Put all of the .aspx files into a folder on the SharePoint Sites Documents page.

What breaks:

• Macros are rendered as static HTML at export time — no interactivity survives.
• Internal Confluence links break entirely (they still point to Confluence URLs).
• No metadata is preserved (author, dates, labels).
• Tables and layouts may render poorly in SharePoint's modern page framework.

Best for: Quick-and-dirty moves where you need readable content in SharePoint but don't care about navigation, links, or metadata.

Method 3: Custom API Scripts (Confluence REST → Microsoft Graph)

For teams with engineering capacity, building custom middleware using Python or Node.js to read the Confluence REST API and write to Microsoft Graph (or PnP PowerShell) gives full control.

How it works:

1. Use the Confluence REST API to enumerate spaces, pages, and attachments (see the REST API extraction section above for endpoint details).
2. Parse the Confluence storage format (XHTML with macro markup) using an XML parser.
3. Transform content into SharePoint's CanvasContent1 JSON format (see the transformation section above for the mapping logic).
4. Create pages via the Microsoft Graph sitePage API. The endpoint is POST /sites/{site-id}/pages with a request body containing the page title, promotionKind (page or newsPost), and canvasLayout with the CanvasContent1 controls. Authentication requires an Entra ID app registration with Sites.ReadWrite.All permission scope.
5. Upload attachments to the Site Assets library via PUT /sites/{site-id}/drive/root:/{path}/{filename}:/content.
6. Rewrite internal links using the URL mapping table built during extraction.

What breaks:

• Confluence Cloud uses a points-based model to measure API usage. Instead of simply counting requests, each API call consumes points based on the work it performs. Starting March 2, 2026, phased enforcement begins for the new rate limits across Jira and Confluence REST APIs.
• On Data Center, admins can configure rate limits; the default can be, for example, 10 every 1 minute. This severely throttles extraction speed for large instances.
• Macro-to-web-part translation is the hardest part. You need to write custom transformation rules for every macro type your wiki uses.
• Migrating comments could bring pages to the maximum size of ~2 MB (technical limitation of SharePoint); switch comment migration off if you experience errors.
• SharePoint page APIs only support a documented subset of web parts, and canvasLayout updates require the full page layout, not partial patches.
• Microsoft Graph returns HTTP 429 (Too Many Requests) when throttled. Implement exponential backoff and honor the Retry-After header.

Best for: Engineering teams with 6+ weeks of runway and fewer than 500 pages with simple formatting.

Method 4: Dedicated Third-Party Tools

Three tools dominate this space:

WikiTraccs — 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. Note: WikiTraccs migrates all your content to SharePoint Online (not on-prem, though).

Tzunami Deployer — A purpose-built migration tool that supports Confluence-to-SharePoint scenarios. It preserves metadata (titles, created/modified dates, authors), maintains page structure, supports attachments and embedded content, automates permissions mapping, and handles link resolution.

Enterprise Bridge (CaseAgile) — Labels and tags on each page are converted into SharePoint enterprise keywords. Owners and contributors of the spaces, pages and files remain the same after migration. Labels on each page come across when migrated to SharePoint.

When evaluating any tool, ask five direct questions:

• What happens to unsupported macros?
• How are internal page and attachment links rewritten?
• Can the tool run delta/incremental syncs?
• How are restricted pages handled?
• What source metadata can be preserved natively versus stored in custom fields?

Mapping Data: Pages, Macros, and Permissions

Confluence Spaces → SharePoint Sites

The most common mapping is one Confluence space = one SharePoint communication site. For organizations with dozens of spaces, group related sites under a SharePoint hub site to replicate the cross-space navigation that Confluence provides natively. Do not map spaces to legacy SharePoint subsites — Microsoft's modern architecture has moved away from that model.

If stakeholders ask for categories, translate that carefully. In Confluence that usually means a mix of space, page ancestry, and labels. In SharePoint, model that as metadata. If you recreate it as deep folder trees, you will make navigation, search, and future cleanup harder.

For a deeper breakdown of metadata strategy, see Mastering SharePoint Information Architecture 2026: Content Types, Metadata & Lists.

How We Preserve Confluence Formatting & Macros

When planning a Confluence to SharePoint migration, the most common question is: How do I migrate from Confluence to SharePoint without losing our page formatting and macros? Maintaining Confluence page layout in SharePoint is difficult because the two platforms use fundamentally different rendering engines. SharePoint does not support nested web parts, and its canvas layout is strictly column-based.

To handle Confluence to SharePoint migration formatting, we categorize every macro into one of three common macro outcomes: Convert (native 1:1 mapping), Rebuild (requires custom SPFx or lists), or Snapshot (rendered as static text/image). WikiTraccs contains explicit transformation rules for a range of Confluence macros, but also applies generic transformations. Macros are transformed on the fly and ideally replaced by something native to the SharePoint world. If there is no SharePoint way of replacing a Confluence macro, WikiTraccs tries to find an approximation (which is more the norm than the exception). Macros so far unknown to WikiTraccs are also transformed, but in a generic way.

Permissions: Confluence Restrictions → SharePoint Permissions

Confluence has two permission layers: space permissions (who can view/edit a space) and page restrictions (who can view/edit a specific page). SharePoint has site permissions (inherited from Entra ID groups) and item-level permissions (which Microsoft discourages at scale — the recommended limit is 5,000 unique permissions per list).

Page restrictions can be migrated to a certain extent, confined to what is technically possible. The WikiTraccs author does not recommend migrating page restrictions. Instead, re-map permissions at the site level using Entra ID security groups, and only apply item-level restrictions where strictly required. Because SharePoint's permission inheritance is managed at the Site, Library, or Item level, replicating Confluence's granular page-level restrictions often means restructuring content into separate Document Libraries.

For detailed guidance on SharePoint permission modeling, see The Definitive Guide to SharePoint Permissions & Security (2026 Edition).

API Limits and Technical Constraints

These are the hard limits that will break your migration if you don't plan for them.

Confluence-Side Constraints

SharePoint-Side Constraints

Migration Risk Register

Every Confluence-to-SharePoint migration carries predictable risks. Use this register to plan mitigations before they become problems.

Step-by-Step Confluence to SharePoint Migration Process

Step 1: Pre-Migration Audit

Before touching any migration tool:

• Inventory your spaces. Count pages, blog posts, attachments, and total storage per space.
• Identify active macros. Which macros are used and how often? This drives your mapping effort.
• Catalog labels. Decide which labels become managed metadata terms vs. enterprise keywords.
• Revise all outdated, deleted, and internal-use content, so that only the necessary information migrates to SharePoint. Conducting an audit in a familiar environment makes this task easier. Check hidden pages — detect any pages called "archive", "outdated", or similar. Undeleted content may reside there.
• Document page restrictions in a spreadsheet with the planned Entra ID group mapping.
• Identify Cloud-only features. If you're on Confluence Cloud, flag pages using whiteboards, databases, or Smart Links — these fall outside standard export paths and need manual handling.

Step 2: Design Your SharePoint Target Architecture

• Map each Confluence space to a SharePoint site.
• Group related sites under hub sites for cross-space navigation.
• Create managed metadata term sets for labels that need to survive.
• Decide on navigation: WikiPakk page tree, custom SPFx, or SharePoint native navigation.
• Pre-create target sites using PnP PowerShell or the SharePoint Admin Center and configure content types.
• Decide what becomes a page, news post, list item, document, or archive record. Not every Confluence page should become a SharePoint page — some content fits better in a document library or a list.

Step 3: Build the Mapping Workbook

Define explicit rules for:

• Page and blog post type mapping (page vs. news post)
• Macro handling rules per macro type
• Label-to-metadata mapping
• Permission mapping (Atlassian groups → Entra ID groups)
• URL rewrite rules (old Confluence URLs → new SharePoint URLs)
• Source metadata columns to preserve (Source Author, Source Created, Source Updated, Source Confluence URL)

This workbook becomes your control plane for QA, redirects, and stakeholder sign-off. Keep it even if you migrate by API.

Step 4: Sample Migrations: What We Test and How We Validate Rendering

Pick a representative space — not the cleanest one. Choose a space with mixed content: text, tables, macros, attachments, images, page restrictions, and deeply nested hierarchies. We use sample migrations as the primary mechanism to prove fidelity and ensure our mapping rules actually work for your specific page structures.

We don't promise "perfect fidelity" out of the box because the platforms are fundamentally different. Instead, we achieve high fidelity through strict human-verified mapping and QA steps specific to page rendering and macros. During this pilot, human QA engineers manually inspect the output to validate rendering.

Validate:

• Page count matches source.
• All attachments are accessible.
• Internal links resolve correctly.
• Macro-heavy pages render acceptably without dropping nested content.
• Confluence page layouts (columns, panels) map correctly to SharePoint sections.
• Author/editor metadata is correct (or stored in custom columns).
• Labels/tags transferred as expected.
• No pages exceeded the ~2 MB limit.
• URL paths stay under 400 characters.

Step 5: Execute Full Migration in Batches

Migrate spaces in batches, not all at once. Batch by business unit or content priority.

• Run migration during off-peak hours to minimize SharePoint throttling. Depending on the usage of Microsoft 365 worldwide and the region you are in, the speed of SharePoint-related operations can vary; migrating on a weekend might be faster than during working hours.
• Load in order: Upload attachments and images first, then create pages that reference them, then apply page-level permissions last. This order makes troubleshooting far easier because you don't have broken pages trying to render files that don't exist yet.
• Monitor for failures: pages exceeding the ~2 MB limit, files with unsupported characters in names, and URL paths exceeding 400 characters.

Step 6: Delta Sync and Cutover

Between your initial migration and cutover day, users are still editing Confluence. Run a delta migration to pick up changes since the last run. Delta detection works by comparing the lastModified timestamp and version.number from the Confluence REST API against the values recorded during the previous extraction — pages where either value has changed are re-extracted and re-transformed. Both WikiTraccs and Tzunami support incremental migrations natively.

On cutover day:

1. Set Confluence spaces to read-only.
2. Run the final delta sync.
3. Validate counts and spot-check high-traffic pages.
4. Update DNS/redirects if you're maintaining bookmarks.
5. Announce the switch to users.

Step 7: Post-Migration QA and Cleanup

No migration is 100% clean on the first pass. Allocate time for:

• Broken link audit — Search migrated pages for URLs still pointing to *.atlassian.net or your Confluence domain.
• Macro residue — Look for placeholder text where macros failed to transform.
• Image verification — Spot-check image-heavy pages to confirm all inline images render.
• Navigation rebuild — Configure SharePoint site navigation to reflect the old page hierarchy.
• Permission validation — Confirm that restricted content is actually restricted in SharePoint.
• Page count reconciliation — Verify total page and attachment counts match the source per space.
• Search testing — Confirm key content is discoverable through SharePoint search.
• Duplicate detection — Check for duplicates caused by title or slug changes during migration.

Example Migration Timeline

Timelines vary significantly based on page count, macro complexity, and the number of spaces. The following estimates are based on typical project phases — adjust for your specific environment.

Post-Migration: Fixing Broken Links and Formatting

Broken links are the #1 post-migration complaint. There are three categories:

1. Internal wiki links (Confluence page → Confluence page)

Tools like WikiTraccs handle this automatically. Will links keep working after migrating from Confluence to SharePoint? Yes. WikiTraccs takes care of this. If you used custom API scripts, you need to build a URL mapping table and do a find-and-replace pass across all migrated page content. Confluence internal links look like /display/SPACE/Page+Title; these must be rewritten to their SharePoint destinations (e.g., /sites/SiteName/SitePages/Page-Title.aspx).

2. Hard links (raw HTTP URLs to Confluence)

Hard links are plain old HTML links that Confluence is oblivious of, from a metadata standpoint. These are harder to detect and rewrite because the migration tool has no metadata about their target. A post-migration script scanning for your old Confluence domain in page content is the only reliable fix.

3. External links pointing IN to Confluence

Bookmarks, emails, third-party docs, and search engine indexes still point to your old Confluence URLs. Set up HTTP 301 redirects from your Confluence domain to the corresponding SharePoint pages. If you're on Confluence Cloud and don't control the domain, you cannot set up redirects — communicate the URL change to users instead.

Formatting issues to watch for:

• Pages in Confluence are much wider than SharePoint modern pages. Wide tables or multi-column layouts will compress or reflow.
• Nested tables are de-nested (content is preserved but layout changes).
• Color-coded text may lose precision — SharePoint has a smaller color palette.
• Inline mentions become links to search results rather than interactive @mentions.
• SharePoint does not support deeply nested tables the same way Confluence does. Complex tables may need to be converted into SharePoint Lists.

Customer Responsibilities and Recommendations

Even with a managed migration, the customer owns the data and the business context. To ensure a successful Confluence to SharePoint migration, we recommend the following:

• Audit and clean up early: Archive obsolete spaces and delete unused pages before the pilot. Do not migrate trash.
• Define macro priorities: Tell your migration partner which macros are business-critical (e.g., a Jira report used for weekly syncs) versus those that can be static snapshots.
• Sign off on the pilot: Review the sample migration carefully. The pilot is your opportunity to flag formatting issues before thousands of pages are processed.
• Manage user communication: Prepare your team for the fact that SharePoint is not a wiki. The authoring experience and navigation will change.

For a complete breakdown of our testing methodology and technical constraints, see our Confluence to SharePoint Migration QA Checklist, the Detailed Technical Guide to SharePoint Migrations, and our FAQ on SharePoint Migration Limitations.

What This Migration Gets You (and What It Doesn't)

Be honest with stakeholders about these trade-offs before starting.

What you gain:

• Unified platform — one Microsoft 365 tenant for docs, communication, and wiki content.
• Copilot and AI features across your knowledge base.
• Entra ID-based identity management instead of separate Atlassian accounts.
• Reduced licensing costs if you're already paying for Microsoft 365.

What you lose (or must rebuild):

• Native page tree navigation. SharePoint doesn't have this without third-party SPFx solutions.
• Interactive macros. Most become static content.
• Confluence-specific integrations (Jira deep links, Confluence-native automations).
• The editing experience. SharePoint's page editor is more constrained than Confluence's.
• Full version history. Confluence version history doesn't transfer natively.

The migration is technically achievable, but the destination platform behaves differently — and users will need to adapt.

When to Bring in a Migration Partner

Self-service tools work well for organizations with fewer than 100 spaces, standard macros (no heavy marketplace add-on usage), internal engineering capacity to run and validate the migration, and tolerance for some post-migration cleanup.

But the complexity scales non-linearly. If your migration has three or more of these traits, it's no longer a content copy project:

• Macro-heavy pages with marketplace add-ons
• Page-level restrictions that must be preserved
• Public or widely shared external links
• Large attachment volumes
• Hard cutover deadline with zero tolerance for downtime
• Strict compliance requirements for metadata preservation
• No appetite for manual cleanup

At ClonePartner, we treat Confluence-to-SharePoint moves as an ETL problem plus a content-design problem. We build custom extraction engines that pull pages, blogs, attachments, and nested macro content directly via the API, parse the proprietary storage format, rewrite all internal links, and map your specific macro inventory to SharePoint web parts — all with zero downtime.

The decision is straightforward: if you can tolerate manual rebuilding and some data loss, keep it lightweight. If you need clean macro handling, permission mapping, URL rewriting, and zero-downtime cutover discipline, engineer it properly or bring in a team that already has.