What Happens to Confluence Page Trees When You Move to SharePoint?

22.09.2026

In Confluence, the page tree does more than organize pages. It tells employees where a topic belongs to, what is above it, and which related page they should open next. A work instruction may be below a process overview. A troubleshooting page may belong to one product version. A policy may make sense only inside its regional or departmental context.

When companies plan a Confluence-to-SharePoint migration, one of the first questions is therefore: Will that structure survive?

The short answer is yes, but it should not be treated as a simple copy-and-paste exercise. Some things to consider:

• Page hierarchies can be mapped to a corresponding SharePoint structure.
• Internal links can be rewritten, labels can become managed metadata, and permissions can be mapped to Microsoft Entra ID and SharePoint.

But the right result is not necessarily a pixel-for-pixel or level-for-level recreation of the old tree. The aim is to preserve how people understand and use the knowledge while adapting the structure to modern SharePoint.

Why a Confluence tree does not map one-to-one to SharePoint

Confluence is built around spaces and parent-child page relationships. Users can expand a tree and move through nested pages as if they were browsing chapters in a manual. Atlassian also provides a Page Tree macro for displaying that hierarchy inside content.

Modern SharePoint uses a different information-architecture model. Microsoft recommends a relatively flat site architecture: separate sites for distinct topics, tasks or areas of work, connected through hubs, navigation and links rather than deeply nested subsites. Pages then sit inside those sites and can be organized and surfaced through navigation, metadata and search. Microsoft’s SharePoint information-architecture guidance describes global, hub and local navigation as separate layers. That creates an important migration decision.

A Confluence page tree represents several things at once:

• the relationship between topics
• the route employees use to browse
• the ownership boundary of a space
• the permission context around certain pages
• years of growth that no longer reflects how the organization works.

In SharePoint, those functions may be handled by different components. One branch may become a site. Another may become a navigation category. Parent-child relationships may be represented through a wiki tree or metadata. Restricted content may need a separate security boundary.

Preserving the tree therefore means preserving its useful logic, not forcing every old level into one new menu.

How the structure is translated 

This diagram shows a Confluence space and page tree passing through migration mapping into SharePoint sites and pages, navigation or an Easy Wiki tree, and metadata, links and permissions.

A Confluence hierarchy is mapped into coordinated SharePoint structures rather than copied into a single destination.

The mapping stage is where the migration becomes an information-architecture project rather than a file transfer. It answers 4 separate questions:

1. Where will the content live?
2. How will employees browse it?
3. How will SharePoint understand the relationships between pages?
4. Who should be able to see and maintain it?

Confluence page-tree elements and their SharePoint targets

There is no universal one-to-one mapping. The following table shows the decisions we make before migrating a representative Confluence space. The table is deliberately decision-led. A page can be technically transferable and still be the wrong content to reproduce in the target environment.

Confluence element	Decision before migration	Possible SharePoint target	What to validate
Space	Is this one ownership and security area, or does it contain several?	SharePoint site, a group of sites under a hub, or a defined wiki area	Ownership, audience, permissions and future maintenance
Top-level page	Is it real content or only a container for child pages?	Landing page, navigation category or destination page	Whether employees need to read it or only use it to navigate
Child page	Should the parent-child relationship remain visible?	Modern SharePoint page plus navigation, metadata or wiki-tree placement	Context, breadcrumbs, related pages and mobile usability
Deep branch	Does the depth help users or reflect years of uncontrolled growth?	Shallower navigation, topic pages, filters or a dedicated site	Number of clicks, naming clarity and findability through search
Page Tree or Children Display macro	Is expandable tree browsing essential to the user journey?	Local navigation or Easy Wiki tree navigation	Familiar browsing, ordering and visibility of child topics
Labels	Which labels are still meaningful, and which are duplicates or variants?	SharePoint managed metadata and Term Store	Controlled values, filters, search and ownership of the taxonomy
Internal page links	Does every source page have a confirmed destination?	Rewritten links to the corresponding SharePoint pages	Broken links, redirected pages and links to archived content
Space and page permissions	Are restrictions intentional, inherited or outdated?	Microsoft Entra ID groups and SharePoint permissions	Access with representative user accounts, not only administrators
Attachments and embedded media	Should the item remain attached to a page or move to a managed library?	Document library, page web part or another mapped component	Version, metadata, access and links from the page
Archived or duplicate branches	Is the content still required in the live knowledge base?	Archive, PDF export, merged page or exclusion from migration	Retention requirements and whether an approved current version exists

4 ways a page tree can change during migration

1. Preserve the familiar tree

For procedural, technical or policy documentation, the hierarchy itself may be useful. Employees understand the subject through its chapters and subtopics, so removing the tree would make the new environment harder to use. In this case, the page relationships can be migrated and rebuilt as hierarchical navigation. Rocketta’s Easy Wiki for SharePoint adds a tree structure for teams that need a Confluence-like way to browse related knowledge pages.

This is often appropriate when:

• the hierarchy is stable and understood
• pages are maintained as one knowledge domain
• users browse by topic rather than relying only on search
• the tree is not so deep that employees lose their position.

2. Split one Confluence space into several SharePoint sites

A Confluence space may contain content owned by different departments, regions or product teams. It may also combine broadly available knowledge with restricted material. Recreating the entire space inside one SharePoint site can preserve the visual tree while carrying the wrong governance model into Microsoft 365.

The better target may be several SharePoint sites connected through a hub or shared navigation. The user journey can remain coherent even though ownership and access are distributed more appropriately. This is often appropriate when:

• branches have different owners
• permission boundaries are materially different
• the content serves distinct audiences
• each branch needs its own lifecycle and publishing process.

3. Flatten a tree that became too deep

Not every inherited level deserves to survive. A seven-level path may reflect how pages were added over time rather than how employees look for information today. Copying all seven levels can make the new SharePoint environment feel familiar to the migration team and frustrating to everyone else.

Some branches are better converted into:

• a shorter navigation path
• a topic landing page
• metadata-based filtersrelated-content links
• search-driven discovery.

This is not a loss of structure. It is a decision to represent the structure in a form that SharePoint can maintain more effectively.

4. Remove branches that should not become live content

Migration inventories often contain empty containers, old project areas, duplicated procedures and pages without a clear owner. Their position in the tree can make them look official even when nobody knows whether they are still valid.

Before migration, each branch should have an outcome:

• Migrate
• Merge
• Rewrite
• Archive
• Exclude.

This prevents the project from reproducing an old information architecture simply because it already exists.

The links must survive with the hierarchy

A page tree is not only what users see in the left-hand navigation. Confluence pages often reference parent pages, sibling pages and content in other spaces. If the visible hierarchy is rebuilt but those internal links still point to Confluence, users will repeatedly fall back into the old system or reach an unavailable page after cutover. During a Confluence-to-SharePoint migration, Rocketta detects links to Confluence pages, identifies their SharePoint destinations and rewrites the links in the migrated pages. Automated redirects from old Confluence URLs can also be added where they are needed.

The link test should cover more than the obvious navigation menu. It should include:

• links inside body text
• links contained in macros or reusable sections
• references between spaces
• links from external documentation or bookmarks
• links to content that will be merged or archived.

Without that work, the tree may appear intact while the knowledge network behind it is broken.

Permissions can change the shape of the tree

Confluence spaces and individual pages may have different restrictions. Some of those restrictions represent real compliance or confidentiality needs. Others may be historical exceptions that nobody has reviewed for years.

Rocketta maps users and permissions to Microsoft Entra ID and SharePoint groups as part of migration planning. But permission mapping should not be treated as a mechanical name-matching exercise. For every restricted branch, teams should confirm:

• who needs access in the target environment
• whether the restriction applies to one page, a whole topic or an entire site
• which group will own that access after go-live
• whether users can still see navigation links to content they cannot open.

This matters because the ideal content hierarchy and the ideal security structure are not always identical. If a branch has a materially different audience, it may need its own SharePoint site rather than complex page-level exceptions.

Why the test migration should include a difficult tree

A proof of concept built from the cleanest, simplest Confluence space proves very little. The representative test space should include the elements that can change the target design:

• several levels of pages
• cross-space links
• attachments and embedded media
• labels used for navigation or filtering
• restricted pages
• common and third-party macros
• content that has changed since its export.

Rocketta’s migration process uses a test migration to check page layout, macros, attachments, links, navigation, metadata and permissions before the production migration. The results are then incorporated into the migration plan. Larger environments can be migrated in waves and validated before final cutover, while the original Confluence environment remains available as a reference until acceptance.

The test should answer these practical questions, not only produce a successful system log:

Can an employee find the same procedure without knowing its new location?

Can a page owner understand where the page belongs and how to update it?

Does a restricted user see the correct branch and nothing more?

Do links lead to the intended SharePoint destination?

Can the team distinguish migrated live content from archived material?

If those tasks fail, the hierarchy is not yet preserved in a useful sense.

What migration owners should decide before approving the target structure

Before the full migration, IT, knowledge management and business owners should agree on the following:

1. Which parts of the existing tree are still useful? Do not assume that age or page count indicates value.
2. Which Confluence spaces should become one site, and which should be split? Base the decision on ownership, audience and security not only the current space boundary.
3. Where is visible tree navigation essential? Use it where employees depend on browsing related knowledge, not automatically everywhere.
4. Which relationships should become metadata? Topics, document types, regions and departments may be more useful as controlled fields than as navigation levels.
5. Who owns each top-level area after go-live? A preserved tree without accountable owners will quickly become outdated again.
6. How will old links and bookmarks be handled? Decide whether rewritten links, redirects or both are required.
7. What will not migrate? Archive and exclusion decisions should be approved, recorded and testable.

These decisions make the migration easier to validate because there is a defined reason for every major structural change.

The page tree should survive as an experience, not a fossil

Employees do not care whether a parent-child relationship was preserved in the migration database. They care whether they can still understand where they are, find the next relevant page and trust that they have reached the right information.

That may require a familiar tree. It may require a flatter navigation model, stronger metadata or several connected SharePoint sites. In many environments, it requires a combination of all four.

Rocketta’s migration approach preserves page hierarchies, adapts page structure to modern SharePoint, rewrites internal links, maps permissions and turns labels into managed metadata. Where a wiki-style browsing experience remains important, Easy Wiki can provide the corresponding tree navigation inside SharePoint.

The best result is not a SharePoint copy of yesterday’s Confluence. It is a knowledge structure employees recognize on day one and the organization can still govern years later.

If you are assessing the future of Confluence, particularly ahead of Atlassian Data Center end of life, review the page tree before choosing the target architecture. It will reveal more about migration effort than the page count alone.

Frequently asked questions: Moving Confluence page tree to SharePoint