RSS

What Migrates Well From Confluence to SharePoint, and What Does Not

A list to be aware of when migrating from Confluence to SharePoint: what arrives close to the original, what only looks like the original, what becomes a snapshot, what becomes a native web part, and where you’ll hit limits.
By Heinrich Ulbricht |

Customers sometimes have the requirement, or the hope, that Confluence content can be migrated to SharePoint 1:1, with no manual refinement at all.

Whether that requirement can be met depends on what you are willing to accept.

I collected what I usually say in demos or write in emails into this post: what works well, what does not, and what to be aware of. At least at the time of writing.

The mark ❗ shows the six points that customers ask about most. They are summed up at the end.

Maps Well to Standard SharePoint

These are SharePoint capabilities.

Formatting

  • Headings, paragraphs, bold, italic, underline, strikethrough, superscript, subscript (Text Formatting)
  • Text alignment and indentation
  • Bullet lists, numbered lists, nested lists
  • Text colors and highlight colors

Structure

  • Tables with merged cells and cell background colors. SharePoint supports both natively since 2025 (Migration Samples: Tables)
  • Nested tables. SharePoint shows them, but a user cannot create them in the SharePoint editor. WikiTraccs creates them anyway (Nested Tables)
  • Table and column widths. SharePoint keeps the widths. Confluence does not always save the widths it shows, so WikiTraccs opens each table in a browser and measure column widths, in an effort to make tables look good in SharePoint (Table Size Optimization)
  • Standard Confluence layouts. SharePoint has page layouts with columns too and supports up to three columns (Migration Samples: Layouts)
  • Images from attachments, inline images, and images with a hyperlink. SharePoint does not show images that live on other (non-Confluence) websites, so WikiTraccs downloads those and attaches them to the SharePoint page (Images)
  • Page attachments. Each page gets a folder for its attachments, in the same place where SharePoint keeps page attachments itself, the Site Assets library (Page Attachments)
  • Links. SharePoint has links. WikiTraccs rewrites every Confluence link to pages, spaces, and attachments so it points at the SharePoint target, also across spaces (Making Sure Migrated Links Work)

Metadata

  • Page author, last editor, and the dates. SharePoint pages have these fields too. WikiTraccs writes the Confluence values into them. For that, it needs to know which Microsoft 365 account belongs to each Confluence user (Author and Editor)

Structured Data

  • Confluence databases. SharePoint has lists, which are tables with columns and rows, much like a Confluence database. Each database becomes one list (Confluence Databases)

Looks Right in SharePoint, but Is Something Else

SharePoint pages have no equivalent for these Confluence elements. WikiTraccs rebuilds each one from what a SharePoint page does have, so the page reads correctly, but the thing itself is gone. Each group is named after the SharePoint gap behind it. The gap is the same for every migration tool.

No Mentions in Page Content

  • @-mentions, user profiles, profile pictures: SharePoint has mentions in page comments only, not in page content. The result is a link that leads to the person in SharePoint. Nobody gets notified, and no profile card opens on hover (User @-mentions)

No Extensions Inside the Text Web Part

In Confluence, the page body is one editor. You write text, and you insert a macro anywhere in that text.

A SharePoint page is different. It is built from blocks, called web parts. One block is a piece of text, another is an image, another is a list. The block for text is the Text web part, and it is the closest thing to the Confluence page body. It takes text, headings, lists, tables, and inline images. It does not take macros, apps, or other custom elements. Even a code block needs its own web part outside the text.

Nothing macro-like, dynamic, or web part-like can be inserted into the text. Every Confluence macro that sits inside the text either needs to be transformed to text, or needs to be moved out of the text web part into its own web part.

Confluence page body                     SharePoint page
┌────────────────────────────┐           ┌────────────────────────────┐
│ paragraph 1                │           │ Text web part              │
│ ┌────────────┬───────────┐ │           │   paragraph 1              │
│ │ cell A     │ cell B    │ │           │   ┌────────────┬─────────┐ │
│ │            │ ┌───────┐ │ │           │   │ cell A     │ cell B  │ │
│ │            │ │ [code]│ │ │           │   │            │ [code]  │ │
│ │            │ │ block │ │ │           │   │            │ moved v │ │
│ │            │ └───────┘ │ │           │   └────────────┴─────────┘ │
│ └────────────┴───────────┘ │           │   paragraph 2              │
│ paragraph 2                │           ├────────────────────────────┤
└────────────────────────────┘           │ Code web part              │
                                         │   [code] block from cell B │
[code] sits in cell B, above             └────────────────────────────┘
paragraph 2.
                                         [code] cannot sit in a table
                                         cell, and a web part cannot sit
                                         inside the text. It moves below
                                         the whole text, after paragraph
                                         2. A marker stays in cell B.
  • Info, note, warning, tip, and panel macros: SharePoint pages have no panel, callout, or info box of any kind. WikiTraccs rebuilds each one with what the Text web part has: tables, colors, and text formatting. A marker shows which macro type it was (Migration Samples: Macros)
  • Status macro: SharePoint pages have no status label in their text. A SharePoint page can have metadata fields, so a status can be stored as a field of the page, but nothing shows such a field inside the text. The result is colored text
  • Task lists: SharePoint pages have no task item you can tick. The result is text that shows each task and its state at migration time. Nobody can tick it
  • Buttons from Handy Macros and Refined Toolkit: SharePoint pages have no button element in text. The result is a hyperlink

Nothing That Hides and Shows Content

SharePoint has a collapsible section, but it works on the level of the page layout. It folds whole blocks of the page, not a few lines inside the text, and it cannot be used inside the text. Inside the text, nothing can hide and show content. Everything in the text is always visible.

  • Expand macro: there is no way to fold a part of the text in SharePoint, and no way to build one today. The content is there, always expanded (Known Macros)
Confluence page body                     SharePoint page
┌──────────────────────────────┐         ┌──────────────────────────────┐
│ > [expand] Details           │         │ Text web part                │
│   (closed)                   │         │   -- expand Details start -- │
└──────────────────────────────┘         │   the details, always        │
                                         │   visible                    │
The expand is closed. The                │   -- expand Details end --   │
reader clicks to see the                 └──────────────────────────────┘
details.
                                         The details are open, and
                                         nothing can close them.
                                         Marker lines show where the
                                         expand started and ended.
  • Tabs: SharePoint pages have no tabs. The content of each tab follows one after the other. A simple tabs macro that is not nested in other content might map to SharePoint collapsible sections one day, one section per tab. That is an idea, not a feature
Confluence page body                     SharePoint page
┌──────────────────────────────┐         ┌──────────────────────────────┐
│ tabs macro                   │         │ Text web part                │
│ ┌───────┐┌───────┐           │         │   -- tab Setup start --      │
│ │ Setup ││ Usage │           │         │   text of tab Setup          │
│ ├───────┴┴───────┴─────────┐ │         │   -- tab Setup end --        │
│ │ text of tab Setup        │ │         │   -- tab Usage start --      │
│ │                          │ │         │   text of tab Usage          │
│ └──────────────────────────┘ │         │   -- tab Usage end --        │
└──────────────────────────────┘         └──────────────────────────────┘

Tab Setup is open. Tab Usage             Both tabs are visible at once,
is hidden until clicked.                 one below the other. Marker
                                         lines show where each tab
                                         started and ended.
  • Third-party show-and-hide macros, for example cloak or toggle macros from apps: the content is shown inline with a marker

Layout Limits

  • Section and column macros (not the standard layouts): SharePoint layouts cannot be nested inside each other, and a layout has at most three columns. WikiTraccs rebuilds them with tables or with marked blocks of normal page content, so the reader can see where a section or column started and where it ended (Migration Samples: Sections and Columns)
Confluence page body                     SharePoint page
┌──────────────────────────────┐         ┌──────────────────────────────┐
│ section macro                │         │ Text web part                │
│ ┌─────────────┬────────────┐ │         │   -- section start --        │
│ │ column 1    │ column 2   │ │         │   -- column 1 start --       │
│ │ ┌─────────┐ │ section    │ │         │   ┌──────────────────────┐   │
│ │ │ [panel] │ │ ┌────┬───┐ │ │         │   │ [panel] text         │   │
│ │ │ text    │ │ │ a  │ b │ │ │         │   └──────────────────────┘   │
│ │ └─────────┘ │ └────┴───┘ │ │         │   text                       │
│ │ text        │            │ │         │   -- column 1 end --         │
│ └─────────────┴────────────┘ │         │   -- column 2 start --       │
└──────────────────────────────┘         │   ┌───────────┬──────────┐   │
                                         │   │ a         │ b        │   │
A section with two columns.              │   └───────────┴──────────┘   │
Column 1 holds a panel and text.         │   -- column 2 end --         │
Column 2 holds another section           │   -- section end --          │
with two columns.                        └──────────────────────────────┘

                                         SharePoint layouts cannot nest,
                                         so the outer section cannot be a
                                         layout. Its columns become marked
                                         blocks, one below the other. The
                                         panel becomes a bordered table.
                                         The inner section is simple and
                                         might become a table.

Missing Web Parts

SharePoint has no web part for these, so the content becomes a link, an image, or a list.

  • Diagrams from draw.io, Gliffy, PlantUML, and BPMN: SharePoint has no diagram editor on a page. The result is an image of the diagram, which nobody can edit in SharePoint. WikiTraccs attaches the raw diagram file to the page as well, so it can be edited in an external editor, and it creates the preview image when Confluence has none (Diagrams, draw.io preview images)
  • Team calendars: SharePoint has no calendar that a page can host. The result is a SharePoint list with a calendar view, one list per calendar. It is not an Outlook or Microsoft 365 group calendar, there is no Outlook synchronization, and the standard SharePoint events block on a page cannot show these lists. A Team Calendar macro on a migrated page stays a placeholder and is not connected to the list (Team Calendars: What Is Migrated, What Is Not)
  • Confluence whiteboards, the built-in whiteboards of Confluence Cloud, not a whiteboard app: SharePoint has no whiteboard on a page. The result is an image. WikiTraccs can also convert a whiteboard into an editable draw.io file and attach it, which is the first way to get an editable whiteboard out of Confluence (Migrating Confluence Whiteboards as draw.io Files)

Macros Migrated as a Snapshot

❗ Almost every macro loses its function in SharePoint. WikiTraccs has four strategies for a macro: a one-to-one transformation to a SharePoint web part, a static snapshot, the macro body without the macro, or a text placeholder. How Do Confluence Macros Look in SharePoint? explains all four and why a one-to-one transformation is rare.

These are examples of macros that get the static snapshot: the macro is replaced by what it showed at migration time, and nothing updates afterwards. The list is not complete, and new macros are added over time. The Known Confluence Macros page has the full list of macros that are worth a mention.

  • ❗ Page tree, table of contents, children display: a static list of links. SharePoint has no live equivalent; our WikiPakk app has one, see the WikiPakk section below
  • Content by label, content report table (Known Macros)
  • Jira issue list: a static table of the issues and a link to Jira (Jira Issue Links and Lists, on Cloud see Confluence Cloud Specialties)
  • Attachments macro: a static list of attachment links (Attachments macro)
  • Table filter: the filter is gone, the table stays
  • Communardo metadata and Comala workflow states: written as page content and labels (Communardo and Comala Metadata)

Mapped to Native SharePoint Web Parts

  • Code block: the SharePoint Code web part (Migration Samples: Macros)
  • Standalone images: the Image web part; inline images stay in the Text web part (Images)
  • Confluence database: the migrated page embeds the SharePoint list (Confluence Databases)
  • Other macros, by configuration: WikiTraccs can turn a macro into any web part on the page, our own WikiPakk web parts included (Convert Macros to Web Parts)

Does Not Work Well in SharePoint

Content Reuse

In Confluence, one piece of content can live on one page and show up on many other pages. SharePoint has nothing that comes close. A page shows its own content only, and there is no way to show a part of another page (Sharing Content Across SharePoint Pages Is Impossible). This is one of the biggest gaps when it comes to knowledge management. It applies to the native macros and to the apps that are built on the same idea.

Confluence                           SharePoint
page Source                          page Source
┌──────────────┐                     ┌──────────────┐
│ ┌──────────┐ │                     │ ┌──────────┐ │
│ │ snippet  │ │ <──────┐            │ │ snippet  │ │
│ └──────────┘ │        │            │ └──────────┘ │
└──────────────┘        │            └──────────────┘
                        │
page A                  │            page A
┌──────────────┐        │            ┌──────────────┐
│ [include] ───┼────────┤            │ ┌──────────┐ │
└──────────────┘        │            │ │ copy of  │ │
                        │            │ │ snippet  │ │
page B                  │            │ └──────────┘ │
┌──────────────┐        │            └──────────────┘
│ [include] ───┼────────┘
└──────────────┘                     page B
                                     ┌──────────────┐
One snippet, shown on                │ ┌──────────┐ │
three pages. Edit it once,           │ │ copy of  │ │
all three pages change.              │ │ snippet  │ │
                                     │ └──────────┘ │
                                     └──────────────┘

                                     Three copies, no link between
                                     them. Edit one, the other two
                                     stay as they are.
  • ❗ Include page macro: the result is a link to the included page
  • ❗ Excerpt include, MultiExcerpt include from Appfire, and Include Content shared blocks from Keysight: the content is copied to the page, one level deep. After the migration, each copy is on its own. A change on the source page does not reach the copies (Excerpt Include Macros)

Rich Content in Comments, Captions, and Links

Confluence allows formatted text, images, and links in places where SharePoint allows plain text only, or nothing at all.

  • Comments: SharePoint page comments hold plain text, and a comment always shows the account that wrote it. A migrated comment cannot keep the Confluence author, date, and formatting. WikiTraccs writes the page comments as page content at the bottom of the page, with author, date, and the reply thread. Inline comments are not migrated (Comments)
  • Rich image captions: SharePoint image captions hold plain text. The result is the caption text without formatting (Known Issues)
  • Links around rich content, for example a link that wraps a block of formatted text: a SharePoint link holds text or one image, not a block. The content stays, and the link is placed next to it

Nesting and Placement Inside the Page

  • Images next to each other: SharePoint puts them on separate lines since 2023. SharePoint has an Image gallery web part that shows images side by side, but it is a block of its own and cannot hold images that sit inside the text. Converting inline images to it would move them out of the text and change the structure of the page, which is why WikiTraccs does not do it (Migration Samples: Images, the reason)
  • Wide tables: SharePoint pages are narrow, the table gets a scroll bar (Migration Samples: Tables)
  • Sections and columns nested in each other, and formatting that spans a nested area (Page Layout)
  • ❗ Nested macros, for example a code block in a table cell: a web part cannot sit inside a table, so the Code web part moves out of the cell and a marker stays in the cell (Nested Macros)
  • Document previews, for example the Word, Excel, PowerPoint, PDF, and View File macros, and video previews from YouTube, Microsoft Stream, or the Multimedia macro: a link to the file or video. SharePoint has web parts that show a document or play a video, but such a web part cannot sit inside the text. These macros usually sit in the middle of the text, so a web part would have to move out of the text to somewhere else on the page. A link keeps the file where the reader expects it
  • Confluence Cloud chart extensions: a placeholder, because Atlassian offers no way to export them (ADF Extensions)

Page History, Hierarchy, and Permissions

  • Page history: the current version only. The Confluence history itself is not reliable, because a changed attachment changes old versions too, and each macro shows old versions in its own way (Exporting Historical Page Versions - It’s Complicated). In SharePoint, version management is clumsy, and a link to an old version does not work well. On Data Center, older versions can go along as PDF files attached to the page (Historical versions as PDF)
  • ❗ Page hierarchy: SharePoint has no page tree. All pages sit in one flat list, the Site Pages library, and there is no parent page. WikiTraccs keeps the Confluence hierarchy as page metadata, but SharePoint shows nothing of it. Our WikiPakk app shows it as a page tree, see the WikiPakk section below (Confluence vs. SharePoint)
  • ❗ Permissions: possible, not a 1:1 copy; the topic got a post of its own (Confluence Page Restrictions vs. SharePoint Permission Inheritance)

Large Pages and Blocked File Types

  • Pages with more than 2 MB of text, and file types that SharePoint blocks (Known Issues)

Macros: The List Is Never Complete

Most of this post is about standard Confluence content and about general ideas like folding text or showing a status. Confluence also has thousands of macros from apps, and every customer uses a different set. The Known Confluence Macros page lists the macros WikiTraccs knows and what it does with each one.

A macro that WikiTraccs does not know keeps its content, if it has any, or becomes a placeholder that shows the macro name and its settings (Macro Placeholders). Macros that carry nothing of value can be left out (Ignoring macros).

WikiTraccs gets new macro transformations all the time. Customers drive that. A customer has a macro that matters, gets in touch, and describes the use case. Then the macro might get its transformation. The FAQ has a simple test for what is possible: try to rebuild the macro on a SharePoint page by hand. If you can, WikiTraccs can too. If you cannot, no migration tool can.

A test migration shows whether the macros that matter to you are covered. Take pages that contain 80 percent of what you need, migrate them with the trial version, and look at the result.

Deliberate Choices in WikiTraccs

Some things WikiTraccs does not do on purpose.

  • No page history. WikiTraccs migrates the current version of a page. The Confluence history is not reliable enough to migrate, and SharePoint versions would not make it better (Exporting Historical Page Versions - It’s Complicated). Where a customer must keep old versions, they go along as PDF files (Historical versions as PDF).
  • No migration into a SharePoint page template. A SharePoint page has little room, and getting the Confluence content into it in good shape is hard enough. A template would take more room away. It would also need a mapping configuration that says which part of the Confluence page goes into which part of the template. WikiTraccs puts the content on a plain page instead (FAQ on page templates).
  • Attachments go where SharePoint puts them. Each page gets its folder in the Site Assets library, which is the place SharePoint uses for page attachments. SharePoint keeps the page permissions and the folder permissions in sync there. Any other location would lose that link. It would need a mapping configuration too (Page Attachments).
  • Predefined metadata mapping. WikiTraccs writes Confluence metadata into a fixed set of designated page fields. There is no mapping configuration. Labels, for example, become text in a field named “Confluence: Labels (WikiTraccs)”. Managed metadata would tie the migration to the term store and pull in more stakeholders. A choice field is right for some customers and wrong for others. Turning the text into managed metadata or a field of your own is a post-processing step. It is possible. Our script library has PowerShell scripts that show how to work on migrated pages.
  • No SharePoint site creation or configuration. You create the target sites, or use existing ones, and point WikiTraccs at them. Which sites to create, how many, with which names, which permissions, which owners, and which retention and sharing settings is a decision of the transformation project, not of the migration tool. Most organizations have a governance model for that, and WikiTraccs fits into it instead of adding a second one.
  • No subsites, hub sites instead. WikiTraccs migrates to the root of a site, as Microsoft recommends for modern SharePoint. Where several spaces belong together, a hub site connects their sites with shared navigation. Subsites and the tenant root site are not targets (Site vs. Subsite).
  • No space permissions. WikiTraccs migrates page restrictions only, within the limits of the flat SharePoint page model. Space and global permissions stay with the site setup you make. My recommendation is to not migrate page restrictions at all (Confluence Page Restrictions vs. SharePoint Permission Inheritance).
  • No user accounts. WikiTraccs does not create accounts in Entra ID. It maps Confluence users to existing accounts, so author and editor come out right (how to map users and groups, walkthrough with screenshots).

The Six Points Customers Ask About Most

Six points come up in almost every conversation before a migration. They are marked with ❗ in the lists above.

  1. No page hierarchy. SharePoint has no parent page and no page tree.
  2. No page tree navigation. Nothing in SharePoint shows where a page sits, and a migrated page tree macro is a static list of links.
  3. A different permission concept. Confluence restrictions inherit down the tree, SharePoint permissions do not (Confluence Page Restrictions vs. SharePoint Permission Inheritance).
  4. No nesting of web parts. A web part cannot sit inside the text or inside a table. A macro that lives inside the text has to move somewhere else on the page. That changes the structure of the page.
  5. No content reuse. There is no way to show a part of one page on another page.
  6. Most macro functions are lost. Almost every macro loses its function, inside the text or not. What stays is a snapshot, the content of the macro, or a placeholder.

What WikiPakk Brings Back

Some points from the lists above are missing functionality in out-of-the-box SharePoint. WikiPakk is our SharePoint app that adds them. It is a separate product from WikiTraccs, and it is not required for a migration. It can be added at any time.

  • Page hierarchy: a page tree and a breadcrumb on every page, permission-aware, with quick search across the hierarchy
  • Table of contents: a web part that lists the headings of the current page, live instead of the migrated snapshot (TOC web part)
  • Children display: a web part that shows the child pages of the current page, live instead of the migrated snapshot (Children Display)
  • Page tree editor: re-order and nest pages with drag and drop, and auto-nest new pages under the current page
  • Bulk move: move all child pages to another parent (Bulk move)
  • Bulk deletion: delete a whole page subtree at once
  • News grouping: group news posts by publishing date in the tree (News by date)

The complete list is in the WikiPakk features documentation.

Older Posts, Kept for History

SharePoint changed a lot between 2023 and 2026. These posts describe a state that no longer exists. They stay online because they show how SharePoint changed.