Replacing Confluence Data Center is not just a page-export exercise. Pages may depend on attachments, macros, permissions, integrations, history, and established publishing routines. A safe migration starts with an inventory and a representative pilot, then moves content in controlled batches with users and security teams checking the results.
Use the process below to define what must move, evaluate a replacement against your operating requirements, and verify the new environment before and after launch.
Start with requirements, not a product shortlist
Teams often rely on Confluence for more than documentation. Spaces, search, permissions, integrations, and publishing processes may support work across IT, engineering, operations, and other departments. Replacing the platform can therefore affect both technical operations and everyday workflows.
Atlassian's planned transition away from Data Center support has prompted organizations to reassess their options. Moving to a cloud service may work for some teams, but data location, compliance review, subscription commitments, and workflow changes can affect whether it is suitable. Organizations with strict hosting or network requirements may need a private, on-premise, or air-gapped deployment instead.
Before comparing platforms, write down the constraints the replacement must satisfy:
- Where data can be hosted, and which data-residency rules apply.
- Identity and access-management requirements, including restricted areas and external access.
- Backup ownership, retention expectations, audit requirements, and network restrictions.
- Which teams need documentation connected to requirements, issues, delivery plans, tests, or decisions.
- Who will administer permissions, workflows, integrations, and ongoing support.
Separate non-negotiable requirements from preferences. This makes it easier to reject unsuitable deployment models early and to test the remaining candidates against real work.
Inventory the current environment
Record the number of users, spaces, personal areas, pages, attachments, integrations, templates, macros, and permission groups. Classify content as active, legally or operationally important, or obsolete. A page count alone is not a reliable estimate of migration effort.
List systems connected to Confluence as well. Authentication, notifications, issue trackers, source control, reporting, and publishing systems can create dependencies that are easy to miss in a page-by-page review.
For each major content area, identify an owner. Pages without a clear owner should be reviewed before migration rather than automatically carried into the new knowledge base.
Define what the migration must preserve
Decide explicitly whether to move page history, comments, labels, favorites, permissions, blog content, attachments, and links. Not every element needs to be preserved, but omissions should be intentional and documented.
Also map the purpose of macros, plugins, and custom features. Do not assume every feature has an identical counterpart in the replacement. Describe the business outcome each feature supports, then decide whether the new platform can provide that outcome or whether the process should be simplified.
Use three content decisions:
- Move unchanged: content that is current and still useful in its existing form.
- Rewrite or restructure: content that is important but needs a new owner, format, or location.
- Retire: content that is obsolete and does not need to remain in the active knowledge base.
This classification can reveal duplicate pages, outdated workflows, and gaps in ownership before they become part of the new environment.
Evaluate the replacement against real work
Check deployment and governance
Cloud deployment can reduce infrastructure administration. Private cloud and on-premise deployments can support other governance requirements, while air-gapped environments require a platform that can operate without a connection to public SaaS infrastructure. Compare these options against your documented rules for data residency, identity, backups, network access, audits, and operational ownership.
Check knowledge and project workflows
A replacement may need to support more than page editing. Product and R&D teams, for example, may need requirements, delivery plans, issues, decisions, test information, and technical knowledge to remain connected.
Evaluate whether teams can configure fields, statuses, layouts, issue types, link types, permissions, and workflows to suit their processes. Also check navigation, search, reporting, automation, and administration. A large feature list does not establish that a platform will fit your operating model.
Include representative users
Test with authors, reviewers, project managers, engineers, and administrators—not only IT. A platform can pass a technical review and still make routine work harder to complete or information harder to find.
One example to assess is ONES.com. The source describes it as supporting project planning, knowledge management, test management, and CI/CD in one workspace, with configurable project templates, fields, statuses, issue types, layouts, link types, workflows, Agile planning, reporting, collaboration, and automation. It also lists Cloud, On-Premise, Private Cloud, and Air-gapped deployment options. Treat these as evaluation points to verify against your requirements, not as a substitute for security, compliance, or operational review.
For a platform where documentation and delivery work share a workspace, test whether its project structures and permissions can represent the different teams and governance rules in your environment. A lightweight knowledge workflow and an engineering workflow may need different fields, statuses, access rules, and reporting.
Run a representative pilot
Choose pilot content from multiple departments and include difficult cases. A pilot made only of clean, public pages will not expose the risks most likely to affect production.
Include examples with:
- Attachments and links to other pages or systems.
- Restricted pages, inherited permissions, or exceptions to group access.
- Complex templates, macros, or frequently used workflows.
- Historical information that users need for legal, operational, or project reasons.
- Content that users rely on in search and day-to-day work.
Use the pilot to test migration rules, target configuration, integrations, and the process for resolving missing or transformed content. Record issues and decisions so the production plan reflects what the pilot actually revealed.
Move in controlled stages
1. Establish scope and governance
Assign decision-makers from IT, security, operations, and the main business teams. Define the migration boundary, success measures, content policies, approval responsibilities, and testing responsibilities.
2. Configure the target workspace
Set up the information structure, roles, permissions, templates, fields, statuses, workflows, and reporting needed for the first teams. Avoid copying unnecessary complexity from the old environment.
3. Validate the pilot
Have content owners check representative pages, links, attachments, search results, access rules, and required history. Security teams should independently confirm that restricted content is visible only to intended users.
4. Plan migration waves
Group content and teams according to business dependencies and readiness. Before each wave, communicate the schedule, any content freeze rules, the support process, and who is responsible for final validation.
5. Support users after launch
Provide practical guidance for search, page creation, review, permissions, and workflow changes. Keep a visible channel for questions, and track recurring issues so administrators can improve the environment after rollout.
Verify the migration
Define verification before moving production content. For each migration wave, check a representative sample against the source and have owners confirm that content is usable in its new location.
- Confirm that expected pages and attachments are present.
- Check important links and integrations, including links between migrated pages.
- Verify permissions for normal users, restricted groups, and relevant exceptions.
- Test search with terms users actually use to locate important content.
- Confirm that required history, comments, labels, and other agreed metadata were preserved.
- Record defects, assign owners, and resolve issues before moving dependent teams.
Also agree on a process for handling content that fails validation. The source material does not specify a universal migration tool or a single preservation method, so confirm the capabilities and limits of the chosen migration approach during the pilot.
Common risks to avoid
Transferring content without review
Moving everything without checking ownership, structure, permissions, and relevance can reproduce problems from the old environment. Preserve important records, but use the transition to improve content quality.
Choosing by feature count alone
Evaluate how each capability works for your teams, approvals, integrations, and administration model. A feature is useful only if it supports the required process in practice.
Leaving users out of testing
Technical validation does not establish that users can find information or complete familiar tasks. Include the people who create, review, and use the content.
Underestimating permissions
Map groups, private areas, external access, exceptions, and inherited permissions before production migration. Access rules can be more difficult to reproduce safely than the content itself.
Make the decision from evidence
A useful selection process produces an inventory, documented migration rules, a tested pilot, and a verified deployment model. Compare candidates against those artifacts rather than treating migration as a direct copy of the old system.
Start with deployment constraints and content ownership, test difficult cases early, then move in batches with user and security validation. That sequence reduces the chance of discovering critical permission, integration, or content problems after the full transition.
Top comments (0)