A Confluence to SharePoint migration moves your wiki spaces, pages, and attachments into SharePoint sites and document libraries, unifying knowledge management under one Microsoft 365 tenant instead of running two separate platforms. At Code Creators, the detail that catches teams off guard almost every time is that there’s no native Microsoft tool for this move at all, Microsoft’s own migration tools were built for SharePoint Server and file shares, not Confluence, so this is third-party or custom-scripted territory from day one. This guide breaks down the planning stages, content mapping rules, the tooling options that actually exist, and the step-by-step execution phases to move your documentation smoothly.
Why Modern Enterprises Migrate Confluence Spaces to SharePoint
Operating two separate knowledge hubs splits team workflows and increases operational costs. Moving team wikis into Microsoft 365 resolves a few core challenges:
- Lower subscription costs. Eliminate duplicate vendor licenses by replacing Atlassian cloud subscriptions with your existing Microsoft 365 licensing.
- Unified workspace access. Connect wiki documentation directly to Microsoft Teams channels, OneDrive libraries, and Power Platform applications.
- Unified security and governance. Enforce consistent Entra ID permission policies, conditional access rules, and Data Loss Prevention controls across all company records.
- Centralized search. Let employees search company wikis, SharePoint document libraries, and Outlook emails from a single search box.
Core Content Mapping: Converting Confluence Elements to SharePoint
Confluence and SharePoint store and present information differently. Understanding how source elements map to target SharePoint containers prevents data loss during the transfer.
| Confluence Source | SharePoint Target |
| Confluence Space | Communication or Team Site |
| Wiki Page & Nesting | Site Page / Modern Page |
| File Attachments | Document Library Assets |
| Blog Posts | News Posts |
| Inline Comments / Macros | Page Comments / Text Web Part |
Mapping Spaces to Sites
In Confluence, content lives inside Spaces (like an HR Space or Engineering Space). In SharePoint, each space maps directly to a standalone modern Site Collection, such as a Communication Site for company-wide news or a Team Site for project work.
Mapping Pages and Formatting
Confluence uses structured page hierarchies, inline macros, and attachments. When you migrate Confluence pages to SharePoint, pages transform into SharePoint Modern Site Pages, file attachments move to underlying Document Libraries, and macros convert into standard Microsoft 365 web parts, such as navigation, tables, or embedded documents, where a direct equivalent exists.
Phase 1: Pre-Migration Discovery and Data Cleanup
Successful migration projects rely on thorough planning before moving any data. Auditing your source environment prevents migrating outdated, duplicate, or irrelevant pages.
Step 1: Run a Full Content Inventory
Audit every space in your Confluence instance. Identify active spaces, archived projects, page counts, total storage volume, and custom macros.
Step 2: Clean Up Obsolete Data
Don’t move dead data into your clean Microsoft 365 environment. Archive old project spaces, delete duplicate file attachments, and remove orphaned pages that haven’t received updates in over two years.
Step 3: Review Unsupported Macros
Confluence relies heavily on proprietary macros, such as page trees, dynamic status macros, and draw.io diagrams. Identify these early so you can replace them with native SharePoint web parts, embedded Power BI visuals, or standard text formatting. In our experience, dynamic status and reporting macros cause more rework than anything else in a migration, since they often pull live data from other Atlassian products with no direct SharePoint equivalent, not just formatted text that converts cleanly.
Phase 2: Choosing the Right Confluence to SharePoint Migration Tool
Manually copying and pasting hundreds of nested wiki pages into SharePoint takes too much time and risks losing formatting, user attribution, and page history. Modern enterprise transfers require automation, but it’s worth being direct about your starting point: there’s no native Microsoft migration path for Confluence content. Microsoft’s SharePoint Migration Tool (SPMT) and Migration Manager are built specifically for SharePoint Server, file shares, and a handful of other cloud sources like Box and Google Workspace. Neither supports Confluence as a source at all. If you were hoping to lean on a free Microsoft tool for this move, that option genuinely doesn’t exist, and it’s better to know that at the planning stage than discover it mid-project.
Your real options fall into two categories:
- Specialized Confluence migration tools, such as WikiTraccs or Tzunami Deployer, purpose-built to parse Confluence’s storage format, reconstruct page hierarchies, and map user accounts specifically for a Confluence-to-SharePoint move.
- Custom migration scripts. For complex or highly customized setups, engineers use Python scripts or direct REST API calls to extract Confluence’s storage format (XHTML) and rebuild modern pages inside SharePoint using the Microsoft Graph API.
General-purpose enterprise SharePoint migration platforms, such as ShareGate, Quest, or AvePoint, are strong tools for SharePoint-to-SharePoint and tenant-to-tenant moves but confirm directly with the vendor whether Confluence is a supported source before assuming it’s covered, since their core strength is elsewhere.
If you’re evaluating which of these paths fits your Confluence environment’s complexity, that’s exactly the kind of scoping call worth having before you commit to a tool. Our SharePoint Migration Services team at Code Creators has planned this exact kind of migration and can help you avoid discovering a tooling gap partway through the project.
Step-by-Step Technical Guide: How to Migrate Confluence to SharePoint
Following a structured methodology ensures your data moves safely without disturbing daily team operations.
Step 1: Provision Target Sites and Permissions
Create your destination SharePoint sites based on your architectural design. Set up Entra ID security groups that mirror your Atlassian user permissions to ensure proper access control from day one.
Step 2: Configure Account and Identity Mapping
Configure identity mapping inside your migration tool. Map Atlassian user accounts (email addresses) to target Microsoft Entra ID accounts so created dates, modified dates, and page author attributes carry over accurately.
Step 3: Run a Pilot Migration
Never start with a full production migration. Select a medium-sized, representative Confluence space containing tables, attachments, and nested pages. Run a test migration to evaluate speed, page formatting, image rendering, and link integrity. We’ve caught macro conversion issues during a pilot more than once that would have quietly broken dozens of pages if they’d only surfaced during the full production cutover instead.
Step 4: Execute the Production Cutover
Once you validate the pilot results and refine your mapping rules, schedule the production cutover during off-peak hours:
- Set the source Confluence space to Read-Only mode to prevent new edits.
- Run the full migration pass using your chosen migration utility.
- Perform a delta migration pass to capture any last-minute content updates.
- Verify link references, navigation structures, and document attachments on the target SharePoint site.
- Redirect old Confluence URLs or inform users to start using the new SharePoint site.
Operational Comparison: Confluence vs. SharePoint Online
| Technical Feature | Atlassian Confluence | SharePoint Online |
| Primary Structure | Spaces and nested pages | Sites, Lists, and Document Libraries |
| Page Layout Engine | Confluence Storage Format (XHTML) | Modern Canvas Page Web Parts |
| File Storage | Inline page attachments | Native SharePoint Document Libraries |
| Access Control | Atlassian Cloud / Crowd Groups | Microsoft Entra ID & M365 Groups |
| Automation Integration | Jira / Automation for Confluence | Power Automate & Microsoft Copilot |
Handling Page Formatting and Macro Conversions
How do custom Confluence macros convert when moving to SharePoint modern pages?
Custom Confluence macros don’t convert into SharePoint natively, since both platforms use different rendering engines. When you migrate content, specialized migration utilities parse proprietary Confluence macros, such as status pills, tables of contents, or dynamic page lists, and convert them into equivalent modern SharePoint components where one exists. A Confluence Page Tree macro, for example, can convert into a SharePoint Quick Links or Navigation web part. Any unsupported macros render as plain text or clean HTML blocks, letting site owners replace them manually with native Microsoft 365 web parts.
Post-Migration Best Practices
Once your content transfers successfully, a few governance practices help ensure user adoption and keep pages organized.
Re-establish Page Navigation and Hub Associations
Connect your new SharePoint sites to central SharePoint Hub Sites. This unifies top-level navigation, applies corporate branding automatically, and enables cross-site search across all migrated team wikis.
Update Hyperlinks and Cross-Page References
Run automated broken-link reports across your new site collection. Update internal page links that previously pointed to *.atlassian.net domain addresses so they point directly to the new SharePoint page URLs.
Conduct User Training and Onboarding
Train team members on creating modern pages, using web parts, editing text blocks, and managing document permissions inside SharePoint. Showing users how to access documentation directly inside Microsoft Teams accelerates platform adoption.
Decommission the Confluence Instance
Keep your old Confluence instance in read-only mode for a brief transition window, typically 30 to 60 days, to allow for data verification. Once validated, export full space backups to cold storage and terminate your Atlassian subscriptions to capture immediate cost savings.
Technical Evaluation Matrix: Migration Approaches
| Feature Capability | Specialized Confluence Tools (WikiTraccs, Tzunami) | Custom Scripting (Graph API) | General SharePoint Platforms (per-vendor confirmation needed) |
| Confluence Source Support | Purpose-built for this source | Full custom control | Confirm directly with vendor |
| Wiki Page Hierarchy Conversion | Advanced / automated | Complex (requires Graph API work) | Varies by vendor and connector |
| User Metadata Preservation | Generally strong | Custom logic required | Varies by vendor |
| Macro Conversion Handling | Converted where a mapping exists | Custom parsing needed | Varies by vendor |
| Setup & Execution Speed | Fast (GUI-driven) | Slow (high engineering effort) | Depends on scope |
Transition Knowledge Repositories Smoothly With Code Creators
Migrating enterprise wikis, preserving document history, re-architecting page structures, and maintaining user access permissions require deep platform expertise. Without structured planning and proper migration tooling, moving away from Confluence risks broken links, lost documentation, and operational downtime.
At Code Creators, our certified Microsoft intranet architects and migration specialists help organizations plan, execute, and secure complex content migrations, and we’ve walked clients through exactly the tooling gap this guide describes, since it’s the first thing that surprises most teams planning this move. From configuring modern intranet hubs to delivering end-to-end data transfers, we help your business unify enterprise knowledge securely inside Microsoft 365.
Schedule a Consultation for SharePoint migration services at Code Creators to plan a Confluence migration around tools that actually support your source platform.


