Confluence to SharePoint Online Migration
IT Partner moves your Confluence spaces into a governed SharePoint Online knowledge architecture in about four weeks, at an estimated $250 per space plus a $2,950 tenant fee — an estimate that becomes a fixed written quote once the inventory is done. Microsoft's SharePoint Migration Tool and Migration Manager do not read Confluence as a source, so the migration runs on a third-party Confluence-to-SharePoint migrator, licensed for the engagement, named in your quote and passed through at cost rather than buried in the fee. What you get: an inventory of every space, page tree, attachment, label, macro, comment thread, permission and stale corner; an information architecture agreed before anything moves — a hub with one site per space, or a deliberate consolidation, with navigation and metadata standing in for Confluence's page tree; one pilot space migrated and signed off on fidelity before any wave; pages converted to modern SharePoint site pages with attachments in document libraries and labels as managed metadata, authors and dates preserved where the source and the API allow; a macro-handling report that says macro by macro what maps natively, what we rebuild, what freezes as static content and what an author has to rework; permissions mapped to Microsoft 365 groups rather than copied one-for-one; internal links rewritten and unresolved ones reported; validation counts you can check yourself; a briefing for the people who will own the pages afterwards; and a decommission plan that keeps Confluence read-only until you are certain. Three boundaries up front: Jira is not in this engagement, rebuilding Confluence macros or Marketplace apps as SharePoint solutions is quoted separately, and content nobody has opened in years is archived rather than copied — because everything you migrate is something Microsoft 365 Copilot will later read.
What this engagement is
Most Confluence-to-SharePoint projects start with a renewal notice rather than a strategy deck. Confluence Server left support on 15 February 2024, and Atlassian has since published an end-of-life path for Data Center: per Atlassian's announcement, new customers stopped being able to buy Data Center licences on 30 March 2026, existing customers can buy and expand until 30 March 2028, and support, critical security fixes and the Data Center-to-Cloud connectors run to 28 March 2029, when licences expire and instances go read-only. That leaves Data Center customers with two honest options — move to Atlassian Cloud, or move to something they are already paying for. If Teams has already replaced Slack and the documents already live in SharePoint, the wiki is usually the last per-seat subscription holding a second collaboration stack, a second identity model and a second compliance boundary in place. The other reason people arrive here is Microsoft 365 Copilot: content in SharePoint is in the Microsoft 365 semantic index for the people who have access to it, and content in Confluence is not — it needs a connector. Both reasons are good ones. They lead to different work, and we will say which one you are actually buying before you buy it. There is no Microsoft path for this. The SharePoint Migration Tool reads SharePoint Server and file shares; Migration Manager adds cloud sources such as Google Drive, Box, Dropbox and Egnyte. Neither reads Confluence. So this migration runs on a third-party Confluence-to-SharePoint migrator — the specialist tool class that includes products such as Tzunami Deployer and Enterprise Bridge — selected against your source and your fidelity requirements, named in the quote with its licence cost shown separately, and proven on a pilot space before we touch anything else. Which source you are on changes the mechanics: Confluence Data Center exposes an XML space-export REST endpoint (added in Confluence 8.3), so exports can be scripted and scheduled, while Confluence Cloud has no space-export REST API at all — tooling either reads content through the paginated Cloud REST API or works from XML space exports an administrator triggers by hand and downloads. Confluence Cloud's bulk endpoints also cap expanded page bodies at 25 results per request and paginate everything else, which is why a large Cloud estate takes longer in elapsed hours than the same estate on Data Center, and why space administrator rights (or higher) on every in-scope space is a prerequisite rather than a detail. None of that changes the destination. It changes the plan, and we would rather you saw the plan. What converts cleanly is more than people expect and less than a vendor datasheet implies. Pages become modern SharePoint site pages in a Site Pages library; attachments land in a document library with the page references relinked; labels become managed metadata or enterprise keywords so they stay searchable and filterable; created and modified dates and page authors are preserved where the source and the SharePoint API allow it. Then come the three things that always need decisions. First, hierarchy: SharePoint has no native parent-child page tree, so the Confluence tree is reproduced deliberately — as site and hub navigation, as a metadata column that records the parent, or as a page-tree web part — and we pick one per space and tell you which. Second, macros, which are the main limitation of this whole exercise: every macro in your estate gets a disposition in a written report — native equivalent, rebuilt as a web part or a flow, frozen as the static content it rendered, or listed for an author to rework — and macros supplied by Marketplace apps or your own custom apps are named and quoted rather than silently dropped. Third, comments and page restrictions, whose fidelity is genuinely tool-dependent: we prove exactly what survives on the pilot space and write it down, instead of promising it in advance. Permissions are where a migration becomes a governance project, and it is worth being blunt about why. Confluence space permissions and page restrictions do not have a clean one-to-one SharePoint equivalent — SharePoint's model is a Microsoft 365 group per site with Owners, Members and Visitors, and item-level permissions are possible but are a liability you inherit forever. So we map rather than copy: group memberships become Microsoft 365 group memberships, spaces that were open to everyone are checked before they are made open to everyone again, and pages that were restricted are either moved to their own site or listed as exceptions for you to decide on. That check matters more than it used to, because after the migration this content is Copilot-readable for whoever can open it — a wiki space that was quietly world-readable inside Confluence becomes a much louder problem once Copilot can summarise it. For the same reason the inventory triages stale content: spaces and page trees nobody has opened in years are archived to a retention location or exported, not carried into the new home. Migrating less, on purpose, is the single biggest quality decision in the project. If you want the full governance and information-architecture design that surrounds this — site provisioning policy, sensitivity labels, lifecycle, permissions model across the whole tenant — that is the SharePoint governance and information architecture review, and it pairs naturally with this migration.
Which one applies to you
Every space, and every macro inside it, gets one of four dispositions during the inventory — before anything moves. This service delivers three of them end to end and prices the fourth honestly instead of forcing it into the fee.
| Migrated as-is (this service) | Migrated with rework (this service) | Rebuilt or replaced (quoted) | Archived, not migrated (this service) | |
|---|---|---|---|---|
| What it covers | Text pages, tables, images, attachments, labels, page properties and author and date metadata that the selected migrator carries across without human intervention. | Pages whose structure depends on macros with a native or near-native SharePoint answer — table of contents, panels, expand, code blocks, child-page listings, status badges — plus the page-tree-to-navigation decision for each space. | Content that depends on a Marketplace app, a custom Confluence app, a Jira integration or a diagram plugin, and anything that has to become a real SharePoint solution — an SPFx web part, a Power Automate flow, a Power App or a Loop component. | Spaces, page trees and attachments with no recent readership and no owner willing to claim them, plus personal spaces and drafts. |
| How | Migrated by the selected third-party migrator, validated by page, attachment and label counts against the source inventory. | Migrated by the tool, then finished by us: macro output converted or rebuilt to the mapping you approved, navigation and metadata configured, links rewritten and checked. | Named in the macro-handling report with the reason, the options and a separate quote, so you decide whether it is worth building. Nothing is dropped without appearing on that list. | Owner confirmation sought, then exported to an archive you keep — XML space export, PDF or both — and recorded in the closeout report rather than copied into the new home. |
| Counts toward the per-space fee | Yes. | Yes. | No — quoted on its own. | No. |
| Our role | We deliver this end to end — this page. | We deliver this end to end — this page. | We name it, explain it, and scope it; whether it gets built is a separate decision. | We deliver this end to end — this page. |
The disposition comes from the inventory data and a conversation with each space owner — page and attachment counts, last-viewed and last-edited dates, macro usage, permission breadth — not from a preference for the column that fits the fee.
The per-space fee assumes a space of ordinary size and macro density for your estate. The inventory counts pages, attachment volume and macro usage per space before the estimate becomes a fixed quote, and spaces materially larger or more macro-heavy than your estate average are priced individually in that quote. Estates above roughly 50 spaces are quoted per estate rather than per space.
Success criteria
What you receive
How the work unfolds
Confirm scope, stakeholders and space owners; obtain space administrator access across the in-scope spaces and SharePoint administrator access in the target tenant; extract the full inventory — pages, page trees, attachments and volume, labels, macros, comments, permissions, restrictions and activity data — from Confluence Cloud or Data Center; and confirm which source path the migrator will use.
Design the target architecture with you — hub and sites, navigation, metadata, permission model — and walk the disposition register space by space with the owners. Select and licence the migrator against your source and fidelity requirements, and confirm the estimate as a fixed written quote on the real numbers.
Migrate one representative space end to end, including its macro handling, navigation and permission mapping. Produce the fidelity report, review it with the space owner, get written sign-off, and feed everything learned — especially about comments, restrictions and macro output — into the wave plan before anything else moves.
Migrate the remaining in-scope spaces in agreed waves: content and attachments moved, labels applied as metadata, navigation and permissions configured, macro handling applied per the approved mapping, and each wave reconciled against the source counts before the next one starts. Archive the spaces dispositioned as archive and record where the archive lives.
Rewrite internal links and produce the unresolved-link report; deliver the per-space validation reconciliation and the macro-handling report with the author rework list; configure search, navigation and promoted results; and run the editor briefing session with the people who will own the content.
Put Confluence into read-only with the agreed banner and communications, hold it there for the period you choose as the rollback path, hand over the archive and the written decommission plan for your Atlassian licence decision, and deliver the closeout report with the evidence, the open exceptions and the rework backlog with owners.
Prerequisites
Who does what
IT Partner
- Run the full inventory of the Confluence estate and produce the disposition register, the architecture design and the permission mapping for your approval.
- Select, licence and operate the third-party migrator, prove it on a pilot space, and report honestly what it does and does not carry across before the production waves.
- Migrate the in-scope spaces, convert pages to modern SharePoint site pages, apply labels as managed metadata, configure navigation, metadata and permissions, and rewrite internal links.
- Produce the macro-handling report with a disposition for every macro found, and the author rework list by page URL.
- Reconcile every wave against the source counts and publish the validation report with the variances explained.
- Brief the people who will own the content and hand over the decommission plan, the archive and the closeout report.
- Say plainly which content cannot move within this scope, why, and what the options and cost would be.
Your team
- Provide the Confluence and Microsoft 365 access, the source-platform confirmation and the storage headroom listed in the prerequisites, in time for week 1.
- Name an owner per space and make them available for the disposition decision, the pilot sign-off and the post-migration confirmation.
- Approve the information architecture, the permission mapping, the macro mapping and the disposition register — these are content decisions only you can make.
- Approve the selected migrator and accept its licence as a pass-through cost in the quote.
- Send the user communications we draft and choose the read-only and decommission dates.
- Own the author rework listed in the macro-handling report, or commission it as a separately quoted engagement.
- Own your Atlassian contract, licence reductions and cancellation, your Microsoft licensing, and the retention of the archive we hand over.
What's not included
Limitations & technical notes
Frequently asked questions
Can Microsoft's SharePoint Migration Tool migrate Confluence?
No. The SharePoint Migration Tool supports SharePoint Server and file shares as sources, and Migration Manager adds cloud sources such as Google Drive, Box, Dropbox and Egnyte. Confluence is not a supported source for either. A Confluence-to-SharePoint migration therefore needs a third-party migrator built for this specific pair — the tool class that includes products such as Tzunami Deployer and Enterprise Bridge — or a custom API-driven build. We select the tool against your source and your fidelity requirements, name it in the quote, and pass its licence through at cost.
What actually happens to our Confluence macros?
Each one gets a written disposition. Macros with a native SharePoint answer — table of contents, info and warning panels, expand, code blocks, child page listings, status labels — convert to the SharePoint equivalent. Macros that rendered dynamic content from another system, such as Jira issue filters or page property reports, become static content, a rebuilt web part, or a page an author reworks. Macros supplied by Atlassian Marketplace apps or your own custom apps are named with options and quoted separately. The macro-handling report lists every macro found, its disposition and the affected pages by URL, so nothing disappears without appearing on a list you have seen.
Will our page tree survive the move?
Not as a page tree, because SharePoint does not have one. Modern SharePoint pages live in a flat Site Pages library, so the hierarchy is reproduced by design: site and hub navigation that mirrors the tree, a metadata column that records each page's parent so views can group by it, or a page-tree web part. We choose per space during the architecture step, show you the result on the pilot, and document the choice. What we will not do is pretend a flat library reads like a Confluence tree without that work.
Do labels, authors and dates come across?
Labels become managed metadata or enterprise keywords, so they stay searchable and can drive filtered views — which is usually an improvement on Confluence labels rather than a copy of them. Page authors and created and modified dates are preserved where both the migrator and the SharePoint API allow it; some fields end up recorded as the migration account. The pilot report tells you exactly which fields behaved which way in your tenant before you commit to the production waves.
What about comments and page restrictions?
Both are tool-dependent, which is why the pilot exists. Confluence page and inline comments often do not become native SharePoint page comments; where they cannot, the options are to append them to the page, export them to the archive, or let them go — your decision, made on pilot evidence and written down. Page restrictions have no clean SharePoint equivalent either: restricted pages are moved to a separate site with its own membership, or listed as accepted exceptions. We do not use SharePoint item-level permissions to imitate Confluence restrictions, because that debt is paid by whoever administers the site for the next five years.
How are Confluence permissions mapped to SharePoint?
Space permissions and Confluence group memberships map to a Microsoft 365 group per site, expressed as Owners, Members and Visitors. It is a mapping exercise with decisions in it, not a copy: Confluence groups that duplicate existing Microsoft 365 or Entra ID groups are consolidated, spaces that were readable by everyone are re-confirmed with the owner before they are made open again, and anything that will not map cleanly goes on an exception list you approve. The mapping document is a deliverable, so you can audit it afterwards.
Does this work for both Confluence Cloud and Confluence Data Center?
Yes, and the source changes the mechanics rather than the destination. Confluence Data Center has had an XML space-export REST endpoint since Confluence 8.3, so exports can be scripted. Confluence Cloud has no REST endpoint that creates space exports at all, so tooling reads through the paginated Cloud REST API — with expanded page bodies capped at 25 results per request — or works from XML space exports an administrator triggers by hand. The same estate is typically faster in elapsed time from Data Center. Confluence Server has been out of support since 15 February 2024; if that is what you are running, the migration is also a security decision.
We are only doing this so Copilot can read the wiki. Do we still need a migration?
Possibly not, and we would rather tell you now. Microsoft ships Microsoft 365 Copilot connectors for Confluence Cloud and for Confluence on-premises, which index Confluence content so Copilot, Copilot Search and Microsoft Search can use it while it stays in Confluence. If grounding Copilot is the whole goal and you intend to keep paying Atlassian, a connector is a smaller project than a migration. Migrate when you want to stop paying for the second platform, consolidate the collaboration stack, or govern the content under one compliance boundary — those are the reasons this service exists.
Will Microsoft 365 Copilot use the migrated content afterwards?
Yes — content in SharePoint sits in the Microsoft 365 semantic index and is available to Copilot for each user according to that user's permissions. That is a benefit and a risk in the same sentence, and it is why this migration triages rather than copies. A stale page nobody has opened in four years becomes a plausible-looking Copilot answer, and a space that was quietly readable by everyone in Confluence becomes a much louder oversharing problem once Copilot can summarise it. Archiving dead content and re-confirming broad permissions before the move is the cheapest Copilot governance you will ever do.
Is there downtime, and what is the rollback?
No downtime. Confluence and SharePoint run side by side throughout, and cutover is an announced date on which Confluence becomes read-only with a banner pointing at the new home. That read-only period is the rollback: if something is missing, the source is still there to check and re-run. You choose how long it lasts, and decommissioning Confluence — and reducing or ending your Atlassian subscription — happens on your schedule after it, not on ours.
What happens to all the links to Confluence in our Teams messages and emails?
They keep pointing at Confluence, because no migration tool can rewrite links held in other systems. Internal links inside the migrated content are rewritten to their SharePoint destinations where they resolve, and unresolved ones are reported by source page. For everything outside, the answer is the read-only period plus a banner on every Confluence page pointing to the new location, and — where your Confluence configuration supports it — redirects on the highest-traffic spaces. We tell you honestly which of your links can be redirected and which cannot before you set the cutover date.
How long should we keep Confluence after the migration?
Long enough that the people who used it stop reaching for it, which is usually one full business cycle rather than one week. We recommend read-only rather than deleted for that period, an archive export you retain independently of the Atlassian subscription, and a decommission plan with a date on it. Your Atlassian contract terms and any retention obligation drive the final date; the plan we hand over states both so the decision is documented rather than drifting.
What does $250 per site plus a $2,950 tenant fee actually cover?
The tenant fee covers the work done once for the whole estate: the inventory, the information architecture and permission model, tool selection and setup, the pilot space and its fidelity report, link rewriting and validation tooling, the editor briefing and the decommission plan. The per-space fee covers migrating one Confluence space into one SharePoint site: content, attachments, labels, navigation, permission mapping, the agreed macro handling and per-space validation. It is an estimate — page count and macro complexity drive effort more than space count does — so the week-1 inventory converts it into a fixed written quote you approve before migration begins, and you pay after you approve delivery. The migrator's licence appears in that quote as a separate pass-through line.
Can you migrate our Jira at the same time?
Not on this engagement. Jira issues, projects, boards and workflows go to a different destination and need a different plan — moving Jira to Azure DevOps is scoped and quoted separately. Where Confluence pages embed Jira content through macros, those macros appear in the macro-handling report with their disposition: kept as a link if Jira is staying, frozen as static content if it is going, or rebuilt if the page depends on it. Telling you which of your pages have that dependency is part of the inventory.
One of our spaces has tens of thousands of pages. Is that a problem?
It is a design question rather than a blocker. SharePoint's list view threshold is 5,000 items and cannot be raised in Microsoft 365, so a very large space becomes a library with indexed columns and filtered views, or is split across more than one site with hub navigation holding it together. We size this from the inventory in week 1, before any content moves. A space that large is also the one most likely to be priced individually in the fixed quote, and the one where archiving stale content pays for itself.
Can the content land in Microsoft Teams instead of SharePoint sites?
It lands in SharePoint either way — every Team has a SharePoint site behind it, and that is where pages and files live. The real question is whether each space should become a standalone communication site in a hub (better for read-mostly knowledge, wider audiences and cleaner permissions) or the site behind an existing Team (better when a single working group owns and edits the content daily). We make that call per space during the architecture step, with you, and the disposition register records the reason.