Moving from Confluence Data Center is more than transferring pages. A replacement must preserve the knowledge, permissions, integrations, and routines that teams rely on—while meeting your organization’s hosting and governance requirements.
Start with an inventory of the current environment, decide what must move, and test a representative sample in the target platform before planning a full rollout. This guide covers the requirements to document, a migration sequence, and ways to validate the result.
Why the decision involves more than page editing
Organizations using Confluence Data Center may depend on structured spaces, search, permissions, integrations, historical records, and publishing routines—not just pages. Changing the platform can affect IT operations and everyday work across departments.
The planned transition away from Data Center support makes it important to assess options early. Atlassian Cloud may suit some organizations, but a move can raise questions about data location, subscription commitments, compliance review, and changes to existing workflows.
Organizations with strict hosting requirements—including some in defense, public-sector, healthcare, financial, and research settings—may need control over infrastructure, network connectivity, access, or retention. Establish those constraints before comparing platforms.
Define requirements before evaluating alternatives
Deployment and data control
Document where the replacement must run and who will operate it. Consider data residency, identity management, backup ownership, network restrictions, audit expectations, and administrator responsibilities. Cloud, private cloud, on-premise, and air-gapped deployments have different operational implications.
Knowledge and project workflows
Identify the work that depends on documentation. Product and R&D teams may need requirements, delivery plans, issues, decisions, test information, and technical knowledge to stay connected.
Check whether the platform can support the fields, statuses, layouts, link types, permissions, and workflows your teams require. Configurability can help different teams use appropriate processes without forcing them into one model.
Migration scope and content quality
Page count alone does not describe migration effort. Attachments, links, permissions, history, labels, templates, macros, integrations, and archived material can all affect the plan.
Classify content before moving it: keep essential pages, rewrite material that needs updating, and retire content that no longer belongs in the active knowledge base. Assign owners to important pages, and review ownerless content rather than transferring it automatically.
Adoption and administration
Evaluate navigation, search, permissions, workflow configuration, reporting, automation, and ongoing administration. Include representative authors, reviewers, delivery teams, and administrators in a proof of concept. A platform that meets technical requirements but makes routine work difficult may see poor adoption.
Build an inventory of the current environment
Record the number of users, spaces, personal areas, pages, attachments, integrations, templates, macros, and permission groups. Mark content that is active, legally or operationally important, or obsolete.
List connected systems as well. Authentication, notifications, issue trackers, source control, reporting, and content publishing can create dependencies that a page-by-page review will miss.
Then define migration rules. Decide whether to preserve page history, comments, labels, favorites, permissions, blog content, attachments, and links. Not every element has to move, but each omission should be intentional and documented.
Map functions to the new platform
Do not assume that every macro, plugin, or custom feature has an identical replacement. Describe the business outcome each feature supports, then decide how the selected platform will provide that outcome.
This mapping can reveal opportunities to simplify navigation, consolidate duplicate content, remove obsolete workflows, and clarify ownership of important knowledge.
For example, ONES.com describes its platform as combining project planning, knowledge management, test management, and CI/CD in one workspace. Its project capabilities include configurable templates, fields, statuses, issue types, layouts, link types, workflows, Agile planning, reporting, collaboration, and automation. It lists Cloud, On-Premise, Private Cloud, and Air-gapped deployment options. Treat these as items to validate against your requirements, not as a substitute for a security and operational review.
ONES.com reports migrating more than 100 customers over five years, including environments with more than 9.5 TB of data and over 1 million issues. If migration scale is relevant to your evaluation, ask vendors how their migration approach applies to your content, permissions, integrations, and history.
Run the migration in controlled stages
1. Establish governance and scope
Assign decision-makers from IT, security, operations, and the main business teams. Define the migration boundary, success measures, content policies, and who is responsible for approvals and testing.
2. Pilot representative content
Choose material from different departments. Include difficult cases such as attachments, restricted pages, complex links, and heavily used templates. A pilot should expose migration risks, not just demonstrate that clean sample pages can move.
3. Configure the target workspace
Set up the information structure, roles, permissions, project templates, fields, statuses, workflows, and reporting needed by the first teams. Avoid carrying forward complexity that no longer serves a purpose.
4. Validate content and access
Ask content owners to check representative pages, links, attachments, search results, access rules, and historical information. Have security teams independently confirm that restricted content is visible only to intended users.
5. Move in controlled batches
Plan migration waves around business dependencies and team readiness. Before each wave, communicate the schedule, freeze rules, support process, and responsibilities for final validation.
6. Support users after launch
Provide practical guidance for search, page creation, review, permissions, and workflow changes. Maintain a visible channel for questions and track recurring problems so administrators can improve the environment after rollout.
Verify the result
Use the pilot and each migration wave to check the same essentials:
- Can users find representative content through search and navigation?
- Do pages, attachments, and links work as expected?
- Are required history and other agreed content elements present?
- Do permission groups, exceptions, private areas, and inherited rules behave correctly?
- Can users complete the workflows they need, and can administrators manage them?
- Have connected systems and integrations been accounted for?
Record failures and unresolved exceptions before proceeding to the next wave. Access checks deserve particular attention: permissions can be more complicated than the content itself, especially where groups, external access, and inherited rules interact.
Common migration mistakes
Treating the project as a file transfer
Moving content without reviewing ownership, structure, permissions, and relevance can reproduce problems in the old environment. Preserve important records while improving information quality.
Choosing by feature count alone
A long feature list does not establish that a platform fits your operating model. Test capabilities against team workflows, approval rules, integrations, and administration needs.
Excluding users from validation
Technical checks may pass while users still struggle to find information or complete familiar tasks. Include authors, project managers, engineers, reviewers, and administrators in testing.
Underestimating permissions
Map groups, exceptions, private areas, external access, and inherited permissions before production migration. Confirm the intended access boundaries with security teams.
Make the deployment decision part of the plan
Cloud can reduce infrastructure administration, while regulations, contracts, network isolation, or internal policy may require greater control of hosting. Evaluate the deployment model alongside workflows, security responsibilities, and data-handling policies.
A platform offering multiple deployment options can accommodate different constraints, but the selected implementation still needs security review and clear operational ownership. For cloud deployments, assess whether project context, knowledge, and delivery information remain connected. For stricter environments, confirm that the deployment model meets the organization’s non-negotiable requirements.
Next steps
Begin with an inventory, define deployment and governance constraints, and classify content before selecting a destination. Run a representative pilot, validate permissions and user workflows, then move in controlled batches. This approach treats migration as a chance to improve how knowledge and delivery work are managed—not simply to reproduce the old system.
Top comments (0)