A Confluence migration usually starts with an inventory: spaces, pages, attachments, macros, links, labels, permissions… Have you forgotten anything? Once you have that inventory, the obvious next step seems to be: move everything on it. But an inventory only tells you what exists and it does not tell you:
- What is still useful
- Which pages duplicate each other
- Whether something that works well in Confluence should work the same way in SharePoint.
A wide table is a simple example. You can migrate the table and preserve all its information but because SharePoint uses different page layouts and components, the result may require excessive horizontal scrolling and be harder for employees to use. Nothing is missing, the migration worked technically. The page still needs attention.
What Not to Migrate from Confluence to SharePoint: How to Determine What Should Be Left Apart
You do not need to review every page individually before migration. First, define the decisions that will shape the quality of the new SharePoint environment. One question is especially useful when setting the migration scope:
Would we create this again today?
If the answer is no, the content needs a deliberate outcome before it receives a new home in SharePoint. It may need to be adapted, merged, archived or excluded rather than migrated as-is.
7 steps to turn a Confluence inventory into a clear, testable migration scope
1. Define What “One-to-One” Should Preserve
A common request our developers hear is: “Can you migrate our Confluence pages one-to-one?”
Before deciding what should and should not migrate, clarify what one-to-one is expected to preserve. Does the page need to look the same? Provide the same functionality? Keep the same structure? Or allow employees to accomplish the same task?
Those requirements can lead to different SharePoint implementations.
Appearance
Some pages need to remain familiar. Employees may rely on a recognizable layout to scan a procedure or find information quickly.
But Confluence and SharePoint use different fonts, spacing, page widths and components. Reproducing every visual detail does not automatically create the most usable SharePoint page.
Functionality
Next, consider what the page does.
- A table presents information.
- A Table of Contents helps users move through a long page.
- A page-tree component exposes hierarchy.
- A Jira integration connects documentation with work items.
The SharePoint implementation may look different while providing the same function.
User Outcome
Сonsider what the employee needs to accomplish by asking if they can:
- Find the right procedure?
- Understand the information?
- Navigate to related knowledge?
- Reach the correct work item?
- Maintain the page afterwards?
A page can look almost identical after migration and still become harder to use.
Once you know what needs to be preserved, you can make the next decision:
Confluence to SharePoint migration: what should move?
2. Decide What to Migrate, Adapt, Merge, Archive or Exclude
Most content needs one of 5 outcomes:
- Migrate — keep it largely as it is.
- Adapt — keep the value but change how it works or appears in SharePoint.
- Merge — combine overlapping content into one maintained source.
- Archive — retain it for reference or compliance but keep it outside the active knowledge base.
- Exclude — do not move it because it no longer has a useful purpose.
This is where the Confluence inventory becomes a migration scope. A page can be technically transferable and still be the wrong content to reproduce in the target environment.
| What you find in Confluence | Risk of copying it as-is | Decision to consider |
| Current, maintained page | Layout or components may work differently | Migrate / Adapt |
| Wide or complex table | May become difficult to read | Adapt |
| Duplicate pages | Uncertainty about the current version remains | Merge / Exclude |
| Outdated process page | Old information looks current again | Archive / Exclude |
| Page without a clear owner | Nobody can confirm its accuracy | Review first |
| Reused content | Copies may later become conflicting versions | Adapt / Merge |
| Important macro | Same function may need a different implementation | Migrate / Adapt |
| Unused customization | Adds migration and maintenance effort | Exclude |
| Inconsistent labels | Poor taxonomy moves into SharePoint | Clean / Adapt |
| Old project area | Historical content enters the live knowledge base | Archive / Exclude |
The obvious cases are now easier to classify. The harder ones are usually the items that should move, but should not be reproduced exactly as they are.
3. Identify Content That Should Move Differently
These three cases deserve particular attention because they can look perfectly acceptable in a migration inventory: complex tables, macros and reused content.
Wide and Complex Confluence Tables
Imagine a frequently used Confluence table with 12 columns. It contains owners, regions, systems, statuses, deadlines, approvals, contacts, document links and notes. The information is current. Employees use it. It clearly needs to move.
But SharePoint pages use different layouts and available widths. A table that was easy to scan in Confluence may become harder to read in SharePoint, particularly on narrower screens. So instead of asking: Can we migrate this table? ask:
What are employees using this table to do?
Depending on the answer, the best SharePoint result may be the same table structure, if it remains usable, several smaller tables, a SharePoint list, or another component better suited to the task. The information stays. Its presentation may change.
Confluence Macros
Macros require the same kind of assessment. A Table of Contents helps users navigate a long page. A page-tree component exposes related content. A Jira integration connects documentation with work items. For each macro, ask:
What function does it provide, and do employees still need that function?
If they do, that functionality needs an appropriate SharePoint implementation. If nobody uses the function anymore, recreating it simply because it appears in the inventory adds unnecessary migration and maintenance work. Get to know more about how we migrate macros here.
Reused Content
Reused content creates another problem. Imagine information maintained on one Confluence page that also appears on another. If migration turns the visible result into two independent SharePoint copies, both pages may look correct at go-live.
Then the process changes. One page gets updated. The other does not. Now employees have two answers. For reused content, decide where the information will be maintained after migration, not only where it should appear.
Once you have identified content that needs a different implementation, look at the content that is worth keeping but needs cleaning first.
4. Clean What Is Still Valuable Before It Moves
You do not need to clean the entire Confluence environment before migration. Focus on issues that would affect trust, findability or maintenance in SharePoint.
Duplicate and Overlapping Pages
Consider:
Travel Policy
Travel Policy 2024
Travel Policy NEW
Travel Policy – Current
Migrating all four successfully does not solve the problem. Establish which source is current. Useful information can be merged, historical material retained where required, and unnecessary duplicates excluded.
Employees should not have to solve the same version problem after go-live.
Labels and Metadata
The same applies to labels:
Germany
DE
Deutschland
German
DACH
Useful labels can be mapped to SharePoint managed metadata and the Term Store. But migrating every existing value would simply reproduce the inconsistency. Decide which terms are useful, consolidate duplicates and establish who will maintain the taxonomy afterwards.
Page Structure
A seven-level Confluence page tree does not automatically need seven levels in SharePoint. Some hierarchy gives employees valuable context. Other hierarchy simply reflects how the environment grew over time.
Depending on ownership, audience, permissions and how people navigate, a Confluence space may become one SharePoint site, several connected sites, a flatter navigation structure, metadata, a wiki-style tree or a combination of these.
Preserve the relationships employees rely on rather than every historical level. Cleaning tells you what is worth keeping. The next step is deciding what should not become active SharePoint knowledge at all.
5. Decide What Should Stay Out of the Active Knowledge Base
Leaving something out of the live knowledge base does not necessarily mean deleting it. An old project space may need to be retained. A superseded procedure may have a compliance requirement. Historical material may still be useful for reference. Those items can be archived where appropriate. Content with no clear purpose deserves more scrutiny. If a page has no owner, ask: Who can confirm that this is still correct?
If an old customization appears in the inventory, ask: Does anyone still rely on it? If an old branch contains duplicates and abandoned material, ask:
Should employees really find this alongside current knowledge?
Archive what must be retained. Exclude what no longer serves a purpose.
At this point, you have a proposed migration scope. Now you need to find out whether those decisions actually work in SharePoint.
6. Test the Difficult Content Before the Full Migration
Do not build a proof of concept from the five cleanest Confluence pages. Choose a representative space containing the elements most likely to challenge the target design:
- a complex table
- a deeper hierarchy
- important macros
- reused content
- attachments
- internal links
- restricted pages
- meaningful labels or metadata
- relevant integrations.
Then validate the result from 3 perspectives.
- Technical Validation
Did the content arrive correctly?
Do the links work?
Are attachments present?
Are permissions correct?
Do the required components function?
2. Content Validation
Did the right content arrive?
Is the current version clear?
Did you preserve duplicates that should have been removed?
Is ownership clear?
3. User Validation
Can an employee find the procedure without knowing its new URL?
Can they understand the complex table?
Can they navigate related knowledge?
Can the owner maintain the page?
Does a restricted user see the correct content?
If those tasks fail, a successful migration log is not enough.
The test results should now give you enough evidence to make the final scope decision.
7. Run a Final Migration Scope Check
Before approving the scope, ask these 10 questions:
- Would we create this again today?
- Is the information still current?
- Who owns it?
- Does another page contain the same answer?
- Does the existing structure still help employees?
- Which macros and integrations are needed?
- Will the current layout work well in SharePoint?
- Are the labels still meaningful?
- Should this remain live, or only be retained?
- What must an employee still be able to do after migration?
Then assign an outcome: Migrate → Adapt → Merge → Archive → Exclude
You now have something much more useful than a page count. You have a migration scope that can be explained, tested and approved.
Key Takeaways: Create a SharePoint Knowledge Base You Can Maintain
A Confluence environment may have been growing for years. During that time, teams change, processes change, projects finish, owners leave, pages accumulate and labels multiply. Migration gives you an opportunity to review those decisions before they become part of the new environment.
The goal is to preserve the knowledge, functionality and context employees rely on while avoiding unnecessary complexity in SharePoint. So before asking: Can we migrate this? ask: Should this become part of the SharePoint knowledge environment we want to maintain tomorrow?
Frequently Asked Questions: What Not to Migrate from Confluence to SharePoint
Planning a Confluence-to-SharePoint migration?
Start with a representative space and see how your real pages, structure, macros, permissions and metadata translate into SharePoint before defining the full migration scope.
