Confluence to SharePoint migration services
Leaving a wiki is not a file copy. The value sits in nested page trees, in the macros that render half your documentation, in space permissions nobody has audited in years, and in the Jira links threaded through all of it. Fixed-fee migration from senior US-based Microsoft engineers: we inventory every space and every macro, agree what becomes a SharePoint page, a web part or static text, map Atlassian accounts and groups onto Entra ID, and move space by space so nobody has to freeze the wiki. One written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
Moving files is a logistics problem. Moving a knowledge base is a design problem: the structure, the rendering and the permissions all have to be rebuilt rather than copied.
Every space is walked to see how deep the nesting really goes and which parent pages are navigation stubs rather than content. The hierarchy becomes navigation, hubs and metadata by design — not an unordered pile of pages nobody can find.
Macros are the single hardest item in a wiki migration and the reason estimates blow up. We count every distinct macro across every space first, then classify each one as rebuild, flatten or retire before the fee is fixed.
Atlassian accounts and groups are a separate identity source from your tenant. Each group is matched to an Entra security group, and space permissions and page restrictions become SharePoint site permissions your admins can actually audit.
Confluence rarely lives alone. We state in the scope whether Jira stays put, what each embedded issue macro becomes, and which cross-product links will keep working after cutover — rather than leaving a wiki full of dead panels.
Spaces move in waves with a delta pass at each cutover, so teams keep writing in Confluence until their own space switches. A documentation set that goes read-only for a fortnight is a documentation set people stop trusting.
Attachments follow their pages into document libraries. Version-by-version history and threaded comments do not transfer natively, so the fallback — usually a read-only archive export — is agreed in writing rather than discovered afterwards.
How it works
A free consultation plus a crawl of every space tells us how many are genuinely live, how deep the page trees run, which macros appear and how often, which groups hold real permissions, and where Jira is embedded. You get a written scope, a target site design, one fixed price, and a wave plan.
Sites, navigation, page templates, metadata and Entra groups are built to the agreed design. One real space — ideally a macro-heavy one people use daily — moves end to end, so rendering, search, permissions and the Jira decision are proven on live documentation before anything else is touched.
Remaining spaces move in waves, each with a delta pass at cutover so nothing written in the meantime is lost. Owners are trained on editing SharePoint pages, the old wiki goes read-only for an agreed reference window on your schedule, and 30 days of hypercare follows.
Every other migration onto Microsoft 365 that starts with a storage product — Box, Dropbox, Egnyte, an old file server — is fundamentally a folder-to-library exercise. The folders have an obvious destination, the permissions have an obvious analogue, and the arguments are about scale and sharing. Confluence is not that. Its unit of content is a page that is written, nested, rendered by macros, restricted, labelled, commented on and linked to from a dozen other pages. Copying the attachments out of it delivers almost none of the value.
The structural mismatch is worth stating plainly, because it is the whole engagement. Confluence nests pages under pages, indefinitely, and people navigate by that tree. SharePoint site pages all live flat in a single Site Pages library on the site; hierarchy is expressed through site navigation, hub associations and metadata rather than through parent-child page relationships. There is no setting that makes SharePoint behave like a wiki tree. What there is instead — navigation, hub sites, page metadata and managed metadata columns (opens in new tab) — is arguably better for finding things later, but only if someone designs it deliberately. Left to a bulk copy, a 600-page space becomes 600 undifferentiated pages in one library.
The tooling gap matters too, and it is worth knowing before you budget. Microsoft's own migration tooling covers file shares, SharePoint Server farms and the major cloud storage services — the documented list of supported sources (opens in new tab) does not include Confluence. So there is no free first-party wizard for this path. The move is done with third-party migration tooling or with scripted extraction against Confluence's API, and either way somebody has to make the page-by-page decisions the tooling cannot make for you. That is the part we scope, and it is why an honest quote requires seeing your spaces first.
This is the working checklist we take into the inventory session. The right-hand column is the point: most rows need a decision from you before any content moves, and the rows that do not are the easy ones.
| In Confluence | Where it lands in Microsoft 365 | Decided before the first pass |
|---|---|---|
| Spaces | A SharePoint communication or team site per space that is genuinely alive, related sites joined to a hub | Which spaces are live documentation, which are abandoned projects, and which should be archived rather than migrated |
| Nested page trees | Site pages in one flat Site Pages library, with the tree re-expressed as site navigation, hub structure and page metadata | How deep the real hierarchy goes, which parent pages are only signposts, and how people will browse instead |
| Macros | Rebuilt as web parts, flattened into static page content, or retired — see the macro table below | Which macros are load-bearing documentation and which are decoration nobody would miss |
| Space permissions and page restrictions | SharePoint site permissions granted to Entra security groups, following group-based access practice (opens in new tab) | Which restrictions are real confidentiality and which are historical accidents that should stop being special |
| Atlassian accounts and groups | Matched to Entra ID users and security groups, with unmatched and deactivated accounts listed for you to rule on | Who has left, who uses a different email address in each system, and which groups are duplicates |
| Attachments | Document libraries alongside the migrated pages, within Microsoft's file size limits (opens in new tab) and with unsupported names (opens in new tab) cleaned first | Whether attachments stay with their page or are consolidated into a shared library per site |
| Labels | Managed metadata columns on the page library, so filtering survives the move and improves | Which labels are a real taxonomy and which are one person's typo repeated forty times |
| Blog posts | SharePoint news posts on the destination site, surfaced through the News web part | Whether historical posts are migrated, archived, or left behind entirely |
| Page history and comments | Current version migrated; prior versions and comment threads preserved in a read-only space export | How far back anyone genuinely needs to look, and where that archive is kept |
| Embedded Jira issues | Links to the live issue, a status snapshot taken at cutover, or removed — per macro type | Whether Jira is staying, and what a reader should see on the page if it is not |
| Space templates and blueprints | SharePoint page templates, so new documentation keeps a consistent shape | Which templates are actually used to create pages today |
| Retention and classification | Rebuilt with Microsoft Purview sensitivity labels (opens in new tab) and retention policies (opens in new tab) | Which controls are enforced today and which exist only in a policy document |
Nothing in Confluence is deleted by any of this. The migration copies, which is why the wiki can stay live and editable through the waves and read-only afterwards while people satisfy themselves that everything arrived.
If a wiki migration overruns, it is almost always the macros. A page that looks like prose can be a table of contents macro, three include macros pulling content from elsewhere, a Jira issue table and a status panel — none of which exist as text in the export. There is no automatic translation for any of them, so each distinct macro is a small decision multiplied by however many pages use it. Counting them first is the difference between a fixed fee that holds and an estimate that doubles.
The classification is deliberately blunt. A macro is rebuilt if SharePoint has a genuine equivalent, flattened if the rendered output is more useful as plain content than as a live component, or retired if nobody would notice its absence. Only a small residue needs anything custom, and where it does, the SharePoint Framework (opens in new tab) is where that work lands — quoted as a line item before you commit, never discovered halfway through.
| Confluence macro family | Typical outcome | Why |
|---|---|---|
| Table of contents, children display, page tree | Flattened or replaced with navigation | These render the hierarchy that SharePoint expresses through navigation and hubs instead, so they become site structure rather than page content |
| Info, note, warning and panel macros | Flattened into formatted page content | The message matters; the coloured box does not. Rewriting them as headed text blocks keeps the meaning and removes a dependency |
| Include page and excerpt macros | Case by case — usually resolved into the page | Single-sourcing across pages has no native SharePoint equivalent, so we either inline the content or promote it to one canonical page that others link to |
| Jira issue and issue-list macros | Link out, snapshot, or remove | Depends entirely on whether Jira is staying. This is the row that most often needs a decision from someone outside the documentation team |
| Attachments and gallery macros | Rebuilt as library web parts | SharePoint surfaces files from a document library directly on a page, which is a close enough match that this row rarely causes debate |
| Task lists and roadmap macros | Rebuilt in Planner, Lists, or flattened | Live task tracking belongs in a tool built for it; where the list is really a historical record, flattening it is honest and cheaper |
| Code block and diagram macros | Preserved as formatted content or embedded images | Formatting survives; anything rendered by a third-party Atlassian app needs its own decision, because that app is not coming with you |
| Marketplace app macros | Retired, replaced, or custom-built | Third-party Confluence apps have no counterpart in Microsoft 365. Each is priced individually, and retiring is often the right answer |
Most teams we talk to are leaving the wiki, not the tracker. That is a perfectly coherent position — Jira's job has no obvious Microsoft 365 equivalent for engineering teams that live in it, and forcing that move to happen at the same time is how a two-month project becomes a two-quarter one. So the default assumption in our scope is that Jira stays, and the work is deciding what its footprint inside the wiki becomes.
In practice that means walking the macro inventory for anything Atlassian-linked and giving each one a destination: a plain link to the live issue for pages where readers need current status; a snapshot of status and summary captured at cutover for retrospectives and decision records, where the point is what was true at the time; and removal for panels that were never read. Where a team decides they do want workflow inside Microsoft 365 afterwards, that is a separate, later conversation about approval and workflow automation in Power Automate rather than something bolted onto a content migration. Once documentation lives in SharePoint, it also becomes discoverable through Viva Connections (opens in new tab) and Microsoft Search alongside the rest of your content, which is usually the reason people wanted the move in the first place.
Most wiki exits sort into the same three phases. The table shows scope and typical timeline rather than prices, because an honest number requires seeing your space list, your macro counts and your permission groups first — the same principle behind how our fixed-fee process works. You get one written price for the whole project instead of an hourly meter that rewards a slow migration.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — Space and macro inventory, then design | Crawl of every space; page-tree depth and page counts; a count of every distinct macro and where it appears; keep, archive and retire decisions; target site and navigation design; the Atlassian-to-Entra group map; the Jira position; a wave plan and cutover dates | About 1 week | Fixed fee — scoped after your free consultation |
| Phase 2 — Build the destination and pilot one space | Sites, hubs, navigation, page templates, metadata columns and Entra groups built; identities mapped; one live, macro-heavy space migrated end to end so rendering, search, permissions and the Jira decision are validated on real documentation | About 1 week | Fixed fee — scoped after your free consultation |
| Phase 3 — Waves, cutover, and wiki retirement | Remaining spaces migrated in waves with a delta pass at each cutover; attachments and labels validated; archive export taken for history and comments; space owners trained on editing SharePoint pages; Confluence set read-only on your schedule; admin handover, then 30 days of included hypercare | 1–2 weeks, plus 30 days of hypercare | Fixed fee — scoped after your free consultation |
Everything lands in the tenant you own. The sites, pages, groups, labels, documentation and admin access are yours throughout, so your team can carry on in-house the moment hypercare ends.
The usual fit is an organization of roughly 20 to 500 people already paying for Microsoft 365 while also paying Atlassian for a wiki that SharePoint (opens in new tab) could host — noticed at renewal, during a consolidation review, or when someone realises the documentation everyone searches is the one place Microsoft Search cannot reach. Engineering-adjacent teams come up most often, usually keeping Jira and moving everything else.
What you are leaving shapes the project far more than where it lands. Content sitting in cloud file storage raises different questions — folder structure, sharing links and sync clients rather than page trees and macros — and those paths are covered by our Box to SharePoint migration services, our Dropbox to SharePoint migration services, and our Egnyte to SharePoint migration services for firms with an on-premises appliance to retire as well. Plenty of companies do both, in either order. Where an old on-premises farm is also in the picture, our SharePoint Server to SharePoint Online migration handles the workflows, forms and custom web parts a content copy leaves behind. Once the pages land, our SharePoint intranet and document management consulting turns them into a workspace with navigation and governance behind it. And because Microsoft 365 Copilot indexes whatever it is allowed to see, teams planning a Copilot rollout want the space permissions remapped before a decade of wiki pages becomes searchable by everyone. Delivered by senior US-based engineers from our Orange County, CA base, remote across all US states.
Related services
Metadata templates rebuilt as columns, Relay workflows recreated in Power Automate, Shield classifications translated.
Site collections, Designer workflows, InfoPath forms, and custom web parts each given their own decision.
Turn migrated pages and libraries into a structured intranet with navigation, metadata, and permissions people can follow.
The inventory, structure design, and wave-planning playbook that applies to any content move onto Microsoft 365.
Why permissions clean-up is the prerequisite nobody budgets for, and how to do it in the right order.
Why a scoped price beats an open meter when the work has a hard cutover date attached.
FAQ
SharePoint has no nested page hierarchy — site pages sit flat in one library. So the tree is rebuilt as site navigation, hub structure and page metadata, and the parent-child relationships people navigate by become links and filters instead of folder depth. That mapping is agreed in design, before a single page moves.
Three outcomes, decided macro by macro. Some have a genuine SharePoint web part equivalent and are rebuilt. Some render content that reads better as plain text, so they are flattened into the page. The rest are retired or need a custom web part, which is a cost we quote before you commit rather than discover mid-project.
Usually not, and we will say so plainly. Most teams keep Jira and only leave Confluence, so the work is deciding what the embedded Jira issue macros become — a link out to the live issue, a snapshot of the status at cutover, or nothing. Each option has a maintenance cost we walk through during scoping.
No. Spaces move in waves and each wave gets a delta pass that picks up whatever changed since the first copy, so people keep editing in Confluence until their own space cuts over. Only the space being cut over that day goes read-only, and only for the hours it takes.
Attachments move into document libraries and stay linked to their page. Full version-by-version history and threaded comments do not transfer natively, so we agree the fallback up front — usually the current version plus an archived read-only export of the space for anything you may need to look back at.
It reflects how many spaces are genuinely live, how deep the page trees run, how many distinct macros appear across them, how many Atlassian groups need mapping into Entra ID, and whether any custom web parts are needed. You get one written price after a free consultation, and nothing starts until you approve the scope.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.