Confluence to SharePoint Migration: The Complete Guide

• Last updated: 12 November 2026
• Migration,SharePoint
• Editorial Team

If you are looking for the button that moves Confluence into SharePoint, it doesn’t exist. Microsoft’s migration tools handle file shares and cloud storage, and Atlassian’s exports were built for backups and archives, not for landing a wiki in another platform. That gap is why Confluence to SharePoint migration is a project with real decisions in it: what to convert, what to archive, what to rebuild, and what to let go.

The timing is pushing more organizations into those decisions. Atlassian has announced that Confluence Data Center becomes read-only in March 2029, and its own stated path forward is Atlassian Cloud, not Microsoft 365. For organizations already running Microsoft 365, SharePoint is a legitimate alternative, but it is a different kind of tool. This guide is honest about both sides: your four migration routes, what Confluence exports and what gets lost, how macros, links, and page structure behave, and a step-by-step plan, all checked against Atlassian’s and Microsoft’s own documentation.

Why Are Organizations Moving Off Confluence?

The main drivers are Atlassian’s end-of-life schedule for its self-hosted products and the desire to consolidate documentation into the Microsoft 365 subscription a company already pays for. The dates are specific, and they are reported consistently across sources that track Atlassian’s announcements.

• Confluence Server. Support ended on February 15, 2024.
• Confluence Data Center. New customers could no longer buy it from March 30, 2026. Existing customers can buy new licenses and apps until March 30, 2028, and the product becomes read-only on March 28, 2029.
• Atlassian’s path forward. Atlassian points customers toward its cloud products. Staying with Atlassian is therefore a move too, which makes this the natural moment to compare destinations.

The consolidation case is the other half. If your files, mail, chat, and meetings already live in Microsoft 365, keeping a separate wiki means another subscription, another identity to manage, and another place for search to miss. SharePoint puts documentation next to Teams, with the same security and compliance tools, which is covered in our overview of which Microsoft 365 plans include SharePoint. Be honest with yourself about the trade, though: SharePoint is excellent at governed documents and intranet pages, and it is not a one-for-one replacement for a wiki’s macros and page-tree behavior.

Is There a Native Tool to Migrate Confluence to SharePoint?

No. Microsoft’s Migration Manager and SharePoint Migration Tool don’t support Confluence as a source, so converting wiki pages into SharePoint pages takes a custom solution, a specialist third-party tool, or a managed migration. Microsoft’s own migration documentation lists file shares, Google Drive, Dropbox, Box, and Egnyte as Migration Manager sources, and Confluence isn’t among them.

A Microsoft support answer on exactly this question is blunt. The SharePoint Migration Tool can upload exported HTML, XML, or PDF files, but they work only as files in a library and not as pages. Getting from a Confluence page to a SharePoint page needs either a custom solution or a third-party tool. Atlassian doesn’t offer an export that targets SharePoint either. Its export formats include Word, PDF, HTML, and XML, and none of them is a ready-made SharePoint page.

What Are Your Options for Moving Confluence to SharePoint?

You have four routes: export and upload as files, script the conversion with APIs, use a specialist migration tool, or hand the project to a managed migration partner, and most real projects mix more than one. The right mix depends on how much of your wiki is alive and how much fidelity you need.

Route	What You Get	What You Lose or Take On	Best For
Export and upload as files	Word, PDF, or HTML files in document libraries	Page links, navigation, labels, and editable pages	Cold, historical spaces
Script it yourself	Modern pages created through the Confluence REST API and Microsoft Graph	Developer time, and handling links and macros yourself	Teams with development capacity
Specialist tool	Pages converted from exported content, with some tools handling links and users	Licensing, and capabilities that vary by vendor	Mid-size wikis
Managed migration	One accountable project covering audit, conversion, validation, and cutover	A partner engagement	Large or deadline-driven moves

A practical pattern is to split the wiki. Archive cold spaces as files, since nobody edits them and the cost of conversion isn’t worth it, and convert the spaces people actually use into modern pages. That split usually shrinks the project substantially. Specialist migration tools exist for Confluence, and their vendors say they convert pages, rewrite links, and map users, but capabilities and pricing vary a lot, so test any shortlisted tool on one real space before you commit.

What Should You Check Before Choosing a Specialist Tool?

Treat a tool’s marketing page as a list of questions, not answers. Before you commit, confirm each of these on one of your own spaces:

• Your edition. Does it support your Confluence edition, Cloud or Data Center, and your version?
• Output type. Does it create real modern SharePoint pages, or only upload files?
• Links. Does it rewrite internal page links, and how does it report the ones it can’t resolve?
• Macros. Which of your macros does it convert, flatten, or drop, and does it tell you?
• Users and permissions. Can it map Confluence users to Microsoft 365 accounts and carry over space access?
• Delta runs. Can it re-run to catch changes made after the first pass, so you can cut over cleanly?
• Reporting and cost. Does it produce a clear report of what moved and what failed, and how is it licensed?

What Does Confluence Export, and What Gets Lost?

Confluence can export a space to HTML, XML, or PDF, and single pages to Word or PDF, but none of these formats preserves a live wiki, so expect to lose or rebuild macros, page links, and navigation. Atlassian’s documentation describes the options, and the details vary by version and by Cloud or Data Center.

• Permission needed. Space export requires the Export Space permission.
• HTML export. Produces an HTML file for each page along with attachments, but excludes blog posts, and comments are optional.
• PDF export. Includes pages but never comments, and includes image attachments only.
• XML export. Works as a backup, containing pages and attachments and optionally comments. Team Calendars aren’t included, and an XML export can only be imported into the same or a later Confluence version, so it protects you but doesn’t move content to SharePoint.
• Word export. Works one page at a time and covers published content only. In Atlassian’s Data Center documentation, only the first 50 attached images are included.

Two lessons follow. First, keep an unzipped copy of every export as a safety net before you convert anything. Second, plan for SharePoint to hold the current version of each page. If page history matters to you for compliance or institutional memory, keep an XML backup or leave Confluence available read-only for a defined period.

How Do You Decide What to Archive, Convert, or Delete?

Triage every space by how alive it is: delete what nobody needs, archive what people only read, convert what people edit, and rebuild what depends on macros, so you spend conversion effort only where it pays off. This single step usually shrinks a Confluence migration more than any tool choice.

Category	How to Spot It	What to Do
Dead	No edits or views in years, and no owner	Delete after a final export for the record
Reference	Read occasionally, rarely edited	Archive as files in a document library
Active	Edited regularly by named owners	Convert to modern SharePoint pages
Macro-dependent	Built around dynamic macros or live data	Redesign before converting, or keep the live data elsewhere

Ask each space owner to confirm the category, because activity data can mislead. A space that looks quiet may be a policy library everyone relies on, and a busy one may be mostly noise. Assigning owners also gives you someone to sign off on the migrated result, which is the best defense against the “where did my page go” complaint after launch.

How Does Confluence Map to SharePoint?

Spaces usually become SharePoint sites, pages become modern site pages, attachments go to document libraries, labels become metadata columns, and space permissions become SharePoint groups, but this is a design you choose, not an automatic conversion. The mapping is where good migrations are won, because it decides how people find things afterward.

• Spaces to sites. Give each department’s or team’s space its own site, or group related spaces under a hub, instead of dumping everything into one site.
• Pages to modern pages. Modern pages in the Site Pages library are list items whose content is stored as structured web part data, which is why conversion tools and scripts build them programmatically.
• Page tree to navigation. Confluence’s parent and child hierarchy doesn’t carry over by itself. Rebuild it as site navigation, hub links, or curated landing pages.
• Attachments to libraries. Files belong in document libraries, where they get SharePoint’s versioning and permissions. Upload them first so the pages that reference them can link correctly.
• Labels to metadata. Turn labels into columns or managed metadata so people can still filter and search by topic.
• Permissions to groups. Replace page-level restrictions with group-based access on sites and libraries wherever you can. It is simpler to run and to audit. If you are also retiring network shares, our guide to moving file server shares into SharePoint covers the same structure decisions.

What Happens to Macros, Links, and Page Structure?

Most Confluence macros have no direct SharePoint equivalent, internal page links break unless they are rewritten, and long, macro-heavy pages need simplifying to perform well in SharePoint. These three issues cause most of the rework in a Confluence migration.

• Macros. Inventory every macro in use and decide for each one: rebuild it as a SharePoint web part, replace it with text or a link, or retire it. Macros that pull in live data, such as issue lists from Jira, are the hardest to reproduce.
• Internal links. Links between Confluence pages point at Confluence addresses. They must be rewritten to the new SharePoint addresses after the pages exist, or readers will land on dead links.
• Page weight. Microsoft’s guidance for modern SharePoint sites recommends no more than 20 web parts on a page and images of 300 KB or smaller. A long Confluence page full of macros and large images may need splitting into several pages.
• Page creation. Microsoft Graph’s SharePoint pages API can create and edit modern pages programmatically, but it supports a limited set of web parts for creation, so complex layouts take extra work.

How Do You Migrate Confluence to SharePoint, Step by Step?

You audit your spaces and macros, choose a route and design the SharePoint structure, export and back up each space, convert and upload the content, rewrite links, and then pilot, cut over, and retire Confluence. The order matters, especially uploading attachments before pages.

• Audit your Confluence environment. List every space with its page count, blog posts, attachments, and the macros in use. Note which spaces are active, which are cold archives, and which hold restricted content, because that decides how each one is migrated.
• Choose a route and design the SharePoint structure. Decide what to archive as files and what to convert to modern pages. Map spaces to SharePoint sites, attachments to document libraries, labels to metadata columns, and space permissions to SharePoint groups.
• Export each space and keep a backup. Export every space in the formats you need, such as HTML for conversion and XML as a backup. You need the Export Space permission, and you should keep an unzipped copy of every export as a safety net.
• Convert and upload the content. Upload attachments first, create pages second, and apply permissions last. Pages can be created with Microsoft Graph’s SharePoint pages API or a specialist tool, and pages that rely on macros need rebuilding or simplifying.
• Rewrite links and verify. Replace Confluence page links with their SharePoint addresses, then check that pages, images, and attachments open correctly and that the navigation matches the old page tree.
• Pilot, cut over, and retire Confluence. Pilot one space with real users, fix what they find, and then go live in waves. Set Confluence to read-only during the transition, and retire it only after validation.

A few practical habits keep this manageable. Migrate one representative space first, ideally one with macros and attachments, because it exposes problems cheaply. Freeze major edits in a space while you convert it, so the version you convert is the version people see. Tell your teams the cutover date well ahead of time, and run Confluence read-only during the transition so nobody edits the wrong copy. Our broader migration checklist covers the surrounding project tasks.

How Should You Handle Permissions and Access?

Rebuild access as SharePoint groups on sites and libraries instead of copying page-level restrictions one by one, and apply permissions last, after the content is in place. Confluence’s permission model, with space permissions plus page restrictions, doesn’t map cleanly to SharePoint’s.

• Start from the space permissions. Translate each space’s groups into SharePoint groups with the right permission level on the matching site.
• Treat page restrictions as exceptions. Move restricted pages to a separate library or site with its own access, which is easier to audit than hundreds of individual page permissions.
• Map users carefully. Confluence usernames and Microsoft 365 accounts must be matched, or authorship and access can end up wrong.
• Test with real people. Ask pilot users to confirm they can open what they should and can’t open what they shouldn’t.

What Changes for Your Users After the Move?

People will edit, find, and organize content differently in SharePoint, so plan training, naming rules, and page ownership alongside the technical migration instead of treating the move as invisible. A technically perfect migration can still fail if people can’t find their way around afterward.

• Authoring. SharePoint’s page editor works with sections and web parts, which feels different from a wiki editor. Give authors templates for common page types.
• Finding things. Navigation and search carry more of the load once the page tree flattens, so invest in clear site navigation, consistent titles, and metadata columns.
• Collaboration. Modern pages support comments, and the content sits next to Teams, OneDrive, and the rest of Microsoft 365, which is the main reason many teams make the move.
• Ownership. Name an owner for every site and review pages on a schedule, so the knowledge base doesn’t decay the way the old wiki did.
• Communication. Tell people the cutover date, where things moved, and who to ask, and publish a short “where did my page go” guide on day one.

How Long Does a Confluence to SharePoint Migration Take?

A small wiki archived as files can take a few weeks, while converting thousands of pages into modern pages typically takes several months, driven mainly by macro use, link rewriting, and permissions. The table below is a planning estimate, not a Microsoft or Atlassian figure.

Wiki Size	Typical Project Length
Under 500 pages, mostly archived	2 to 4 weeks
500 to 5,000 pages	4 to 10 weeks
5,000 to 20,000 pages	8 to 16 weeks
20,000+ pages or heavy macro use	16 to 30 weeks or more

Heavy macro use, many restricted pages, large attachment volumes, and a strict no-downtime requirement all push a project toward the top of its range.

What Are the Most Common Confluence Migration Mistakes?

The most common mistakes are expecting a one-click tool, migrating everything including dead content, and discovering macros and links only after the pages are in SharePoint. Nearly all of them come from skipping the audit.

• Expecting a native tool. None exists, so plan and budget for conversion.
• Migrating dead content. Years of abandoned spaces inflate cost and clutter search. Archive or delete them.
• Skipping the macro inventory. Macros are the largest source of surprise rework.
• Forgetting to rewrite links. Readers hit dead links the day you go live.
• Uploading pages before attachments. Pages then reference files that aren’t there yet.
• Treating one export as a backup. Keep an unzipped copy and an XML backup before converting anything.
• Mirroring the page tree one for one. A deep hierarchy becomes poor navigation in SharePoint. Redesign it.
• Losing page history unknowingly. If history matters, plan to keep Confluence read-only or retain an XML backup.
• Switching off Confluence too soon. Keep it read-only until validation is complete.

Should You Do It Yourself or Use a Managed Migration?

Do it yourself for a small wiki you can archive as files, and use a managed migration when you have thousands of pages, heavy macro use, complex permissions, or a deadline you can’t miss. The deciding factor is usually developer time, since converting pages is software work, not a copy job.

Situation	DIY Is Fine When	Managed Makes Sense When
Wiki size	A few hundred pages, mostly archival	Thousands of active pages
Macros and links	Few macros, simple structure	Heavy macro use and dense internal links
Permissions	Open or simple spaces	Restricted spaces and page-level permissions
Developer capacity	You have developers to script conversion	You don’t, or they are committed elsewhere
Deadline and risk	Flexible timing	A hard date, such as a Data Center renewal

If you are weighing options for a larger project, our migration services cover every layer.

Moving Other Content Into Microsoft 365 Too?

A wiki is rarely the only repository. We have guides for migrating Box to SharePoint, migrating Egnyte to SharePoint, and moving Google Drive to OneDrive and SharePoint.

How Does Apps4Rent Help with Confluence Migrations?

Apps4Rent plans and runs the full migration, from auditing your spaces and macros to conversion, link rewriting, and cutover, so you get a working SharePoint knowledge base instead of a pile of exported files.

• Audit. A review of your spaces, page counts, attachments, macros, and restricted content, with a recommendation on what to archive and what to convert.
• Design. A SharePoint structure that fits how your teams work, with permissions simplified into groups.
• Conversion. Exports, page creation, attachment upload, and link rewriting handled as one workflow, with a pilot space first.
• Validation. Pages, images, links, and access checked with real users before Confluence is retired.
• Support. A single point of contact, with 24/7 phone, chat, and email support throughout.

FAQs About Confluence to SharePoint Migration

1. Does Microsoft have a tool to migrate Confluence to SharePoint?

   No. Microsoft’s Migration Manager and SharePoint Migration Tool don’t support Confluence as a source. The SharePoint Migration Tool can upload exported HTML or PDF files, but only as files in a library, not as SharePoint pages, so converting pages takes a custom solution, a third-party tool, or a managed migration.

2. How do I migrate Confluence to SharePoint?

   Audit your spaces and macros, choose which content to archive and which to convert, export each space and keep a backup, then convert and upload with attachments first, pages second, and permissions last. Rewrite internal links, pilot one space, and cut over with Confluence set to read-only.

3. Can Confluence pages become SharePoint pages?

   Yes, but not automatically. Modern SharePoint pages can be created programmatically through Microsoft Graph’s SharePoint pages API or by specialist tools that convert exported content. Complex layouts need simplifying, because Microsoft recommends no more than 20 web parts on a modern page.

4. What happens to Confluence macros in SharePoint?

   Most macros have no direct SharePoint equivalent. Inventory them first, then rebuild each as a web part, replace it with plain text or a link, or retire it. Macros that pull in live data, such as issue lists from Jira, are the hardest to reproduce.

5. How do I export a Confluence space?

   Open the space settings, choose the export option, and select HTML, XML, or PDF, with Word available for single pages. You need the Export Space permission. HTML exports exclude blog posts and PDF exports exclude comments, and Cloud and Data Center options differ, so check Atlassian’s documentation for your edition.

6. Does a Confluence export include attachments and comments?

   HTML and XML exports include attachments, and comments can be included in some exports, while PDF exports include only image attachments and no comments. Exactly what you get depends on your Confluence version, so test an export of one space before planning the project.

7. Can I just upload a Confluence export to SharePoint?

   You can upload exported HTML, PDF, or Word files to a document library, but they behave as files, not pages. Links between pages, navigation, and labels are usually lost, so this approach suits cold archives and not active documentation.

8. When does Confluence Data Center reach end of life?

   Atlassian has announced that Confluence Data Center becomes read-only on March 28, 2029. New customers could no longer buy it from March 30, 2026, and existing customers can buy new licenses until March 30, 2028. Confluence Server support already ended on February 15, 2024.

9. How long does a Confluence to SharePoint migration take?

   A small wiki archived as files can take a few weeks, while converting thousands of pages to modern pages typically takes several months, depending on macro use, link rewriting, and permissions. Pilot one space first to measure the real effort.

10. When should I use a managed migration instead of doing it myself?

    Consider a managed migration when you have thousands of pages, heavy macro use, complex space permissions, or a hard deadline, or when you lack developers to script the conversion. Apps4Rent plans, converts, validates, and cuts over as one project.