Atlassian Cloud migration checklist. What to check first
Atlassian Server support ended in February 2024, which means support and bug fixes are no longer available for Server products. Any remaining Server estate should now be treated as an operational risk, not just an old hosting choice.
Many organisations did not migrate immediately. Some delayed investment, prioritised other transformation programmes or adopted phased migration approaches. As a result, Atlassian Cloud migration remains an active priority for many CTOs, Heads of Platform and Engineering leaders in 2026.
For teams still running Jira, Confluence or Bitbucket Server, an Atlassian Server to Cloud migration should start with estate cleanup, not tool execution. For CTOs and platform leaders, the risk is not only a failed migration window. It is carrying broken workflows, poor permissions and avoidable support costs into Cloud.
Atlassian Cloud migration is the process of moving Jira, Confluence and Bitbucket from Server or Data Centre environments into Atlassian Cloud. It can involve users, permissions, apps, workflows, Confluence spaces, Bitbucket repositories, integrations and post-migration validation.
Organisations typically move to Cloud to reduce infrastructure management overhead, simplify upgrades, improve security and identity management and gain access to new Atlassian capabilities. Those benefits are real, but they are not automatic.
If your estate is currently on Data Centre, the migration profile may differ in some areas. Confirm current Atlassian documentation for your source environment before committing to a migration path.
The goal is not to move everything. The goal is to move what still has value, remove what no longer does and avoid rebuilding old complexity in a new platform.
Atlassian’s migration resources cover planning, app assessment, pre-migration checklists, migration assistants and post-migration tasks. This is not just a technical export/ import exercise. The organisations that gain the most value from migration are usually the ones that treat it as an opportunity to improve the estate rather than simply relocate it.
The success of an Atlassian Cloud migration is usually determined long before any migration tooling is opened. The organisations that experience the fewest problems after cutover are typically those that spend time understanding their estate, removing unnecessary complexity and making deliberate decisions about what should and should not move to Cloud.
The first step is defining scope.
1. Confirm your migration scope before touching the tools
Before opening a migration assistant, define exactly what you are migrating.
For Jira, identify the projects, workflows, schemes, custom fields, automations, users and integrations that form part of the estate.
For Confluence, review spaces, permissions, attachments, macros and ownership.
For Bitbucket, review repositories, pull requests, pipelines, permissions and connected delivery tools.
A clean single-instance Server migration is very different from a fragmented Atlassian estate with multiple administration models, duplicate environments, inconsistent permissions and undocumented dependencies.
The first decision is not how to migrate. It is understanding the scope, dependencies and governance requirements of the estate you intend to move.
Build a migration scope that identifies:
- Products in scope
- Projects, spaces and repositories in scope
- Critical integrations and dependencies
- Business processes that must be preserved
- Regulatory, security and compliance requirements
- Owners responsible for validation and sign-off
The objective at this stage is visibility. Before migration planning can begin, you need a clear picture of what exists, what depends on it and who is accountable for it.
A common failure pattern is opening migration tooling before understanding the estate. Migration tools can move information, but they cannot identify hidden dependencies, undocumented ownership or governance risks. Those decisions must be made before migration begins.
2. Clean up Jira before you migrate it
Jira is often the highest-risk part of an Atlassian Cloud migration because it carries years of delivery history, process design decisions and operational habits. Over time, Jira estates accumulate inactive projects, duplicate workflows, abandoned boards, unused custom fields, legacy permissions and administrative complexity that no longer reflects how the organisation actually works.
Once the migration scope has been defined, the next step is deciding what deserves to survive the move to Cloud.
Cloud migration is the wrong moment to preserve unnecessary complexity. The question is not ‘can we move this?’ It is ‘does this still add value?’
Start by reviewing:
- Projects that are complete, inactive or duplicated
- Workflows that no longer reflect how teams work
- Schemes that exist only because nobody has retired them
- Custom fields with unclear purpose or low usage
- Boards, filters and dashboards relied upon by active teams
- Automations, webhooks and mail handlers
- User groups, administrative permissions and external access
- Integrations with reporting, CI/CD, service management and finance systems
Jira consolidation is not automatically required before moving to Cloud, but it should be assessed as part of migration planning. Consolidation may be justified where multiple Jira instances create fragmented reporting, duplicate workflows, inconsistent permissions, governance challenges or unnecessary migration complexity.
For a deeper decision framework, see Catapult CX’s guide on when Jira consolidation is justified.
Migration tools can move data, but they cannot determine whether a workflow still supports the business, whether a permission model remains appropriate or whether an inherited configuration still adds value. If Jira is difficult to govern today, migrating it unchanged will simply make the same problem cloud-hosted.
For organisations with unclear Jira ownership, app sprawl, complex workflows or several Jira instances, Catapult CX’s Atlassian Excellence Review can assess projects, workflows, permissions, apps and governance before committing to a migration path.
Jira migration validation checklist
Before migration, confirm:
- Which projects should move, archive or be retired
- Whether duplicate workflows and schemes can be simplified
- Which custom fields remain necessary
- Whether boards, filters and dashboards still support live delivery
- Whether automations and webhooks are functioning as intended
- Whether user groups and permissions are accurate and governed
- Whether Marketplace applications require Cloud equivalents or alternatives
- Whether external integrations need rebuilding or redesign
- Whether reporting and dashboards will remain trusted after migration
Also identify any Jira components that may require manual migration work or post-migration validation. Depending on the migration path and tooling used, dashboards, filters, webhooks, mail handlers, project shortcuts and configuration data may require additional checking after cutover.
3. Review Confluence spaces, permissions and macros
Confluence migration is not simply about moving pages from one platform to another.
A Confluence estate often contains policies, technical specifications, architectural decisions, operational runbooks, product knowledge and years of informal organisational knowledge. Some of that information is critical to day-to-day operations. Some will be outdated, some duplicated and some may be sensitive or poorly controlled.
Before migration, review:
- Spaces that are actively used or should be archived
- Page ownership and content accountability
- Space permissions and restricted pages
- Public access settings
- Attachments and embedded files
- Macros, templates and legacy formatting
- Links to Jira issues, projects and dashboards
- User mapping and email address consistency
The bigger risk is not losing information during migration. It is moving a poorly governed knowledge estate into Cloud and assuming the migration has solved the underlying problem.
If a space has no owner, no update history and no clear audience, ask whether it belongs in the Cloud environment at all. Knowledge that is no longer trusted, maintained or understood creates noise, increases risk and makes valuable information harder to find.
Macros require particular attention.
Built-in and Marketplace macros can behave differently in Cloud environments, Marketplace macro migration depends on vendor support and some legacy or deprecated macros may require replacement or redesign.
Migration should leave Confluence easier to govern, easier to trust and easier to use. If the estate remains cluttered, unowned and poorly controlled after migration, the organisation has simply moved the problem rather than solving it.
4. Treat Bitbucket migration as a code and delivery risk
Bitbucket migration is often under-estimated because repositories appear simpler than Jira workflows or Confluence spaces. That is a mistake.
Bitbucket problems often surface immediately after migration because they directly affect build pipelines, release processes and engineering productivity. A workflow issue in Jira may be inconvenient. A broken deployment pipeline can stop software delivery entirely.
Because unlike Jira and Confluence, Bitbucket sits directly within the software delivery chain. It contains source code, branches, pull requests and deployment dependencies and is often connected to build pipelines, release controls, security scanning, deployment approvals and operational reporting. Migration issues can therefore affect engineering productivity, release confidence and production delivery immediately after cutover.
Before migration, review:
- Active, inactive or duplicated repositories
- Repository permissions and inherited group access
- Pull requests and branch history
- Pipelines and deployment dependencies
- SSH keys and app passwords
- Git LFS requirements
- Submodules and repository references
- Marketplace app data
- Integrations with Jira, CI/CD tools and deployment systems
Do not treat Bitbucket as ‘just code storage’. For each repository, ask the same question as Jira – does this still reflect how the organisation delivers software today?
Repositories with no clear owner, disconnected pipelines, obsolete integrations or little ongoing value should be archived or retired before migration rather than moved unchanged.
Some Bitbucket data and settings may require manual handling or post-migration validation, including Git LFS, submodules, repository settings, SSH keys, app passwords and Marketplace app data. These dependencies should be identified before migration planning is finalised.
5. Audit apps, integrations and licences before migration
Marketplace applications are one of the most common causes of migration complexity and post-migration surprises.
A migration may look straightforward until a business-critical app has no Cloud equivalent, application data requires a separate migration path, or different teams rely on different tools to perform the same function.
Before migration, build a complete app inventory:
- Which apps are installed?
- Who owns them?
- Who uses them?
- What business process depends on them?
- Is there a Cloud version?
- Does the vendor support data migration?
- Is native Atlassian Cloud functionality now sufficient?
- Are multiple apps performing the same function?
- Are any apps unused but still licensed?
- Does the app affect reporting, workflows, compliance, security or automation?
Do the same for integrations. Jira, Confluence and Bitbucket may connect to identity providers, reporting tools, service desks, CI/CD pipelines, Slack or Teams, data warehouses, finance systems and audit platforms. Understanding those dependencies before migration reduces the risk of unexpected failures after cutover.
Licences should also be reviewed. Migration provides an opportunity to remove inactive users, retire redundant applications and avoid carrying unnecessary cost into the Cloud environment.
Many Atlassian estates accumulate applications over years of incremental change. Teams adopt new tools, projects come and go, ownership changes and original decisions are forgotten. Migration is an opportunity to rationalise that complexity rather than preserve it.
The rule is simple. If an app, licence or integration is not owned, understood or actively used, do not migrate it by default.
6. Validate users, permissions and security controls
User migration is not administrative housekeeping. It affects access, ownership, auditability, security and user adoption across the Atlassian estate.
Before migration, check:
- Duplicate or invalid email addresses
- Inactive users
- External users and partner accounts
- Administrative groups
- Restricted groups
- Project and space permissions
- Public access settings
- SSO requirements
- MFA requirements
- User provisioning processes
- Audit log requirements
Jira, Confluence and Bitbucket all depend on accurate user and group mapping. If identities are poorly managed before migration, permission issues, ownership gaps and security risks can follow the estate into Cloud.
Security controls should also be reviewed before cutover.
Confirm authentication methods, access controls, administrative privileges, group structures, public access settings, data exposure risks and post-migration monitoring requirements.
Migration is often one of the few opportunities organisations have to rationalise years of accumulated access decisions. Users change roles, contractors leave, projects end and permissions are rarely cleaned up as often as they should be. Cloud migration provides a natural point to revalidate who should have access to what and why.
This is particularly important in regulated environments where audit trails, access controls and accountability must be preserved throughout the migration process. The goal is not simply to move users into Cloud. It is to leave the estate easier to govern, easier to secure and easier to audit than it was before migration.
7. Run a test migration before production cutover
A migration is not successful because the tooling completed successfully. It is successful when users can work normally in the new environment and the organisation can operate with confidence after cutover.
A test migration should answer:
- How long will the migration take?
- What downtime should users expect?
- Which data moved cleanly?
- Which apps need additional work?
- Which permissions changed?
- Which integrations broke?
- Which dashboards, boards, pages or repositories require validation?
- Which user groups will need support before go-live?
The purpose of a test migration is not simply to prove that data can move. It is to identify risks, dependencies and unexpected behaviours while there is still time to address them.
User acceptance testing should involve real users, not just administrators. Jira users should test boards, backlogs, workflows, filters and dashboards. Confluence users should test spaces, pages, attachments, permissions and links. Bitbucket users should test repositories, pull requests, access controls, pipelines and connected release processes.
Post-migration validation should cover Jira issue links, Confluence page links, integrations, permissions and application behaviour before the source environment is decommissioned.
Migration should be treated as a risk-management exercise rather than a simple hosting change. The objective is not merely to complete the migration. It is to ensure that teams can continue delivering, collaborating and operating without disruption once the transition is complete.
Catapult CX explores that wider principle in its guide to cloud migration strategy.
Common Atlassian Cloud migration mistakes
Most migration failures are not caused by migration tooling.
They are caused by poor preparation, weak governance and assumptions that are never tested before cutover.
Common mistakes include:
- Migrating the estate before completing cleanup and rationalisation
- Treating migration as an infrastructure project rather than a governance and operating model decision
- Failing to identify critical Marketplace app dependencies
- Migrating inactive users, abandoned projects and obsolete content
- Assuming Cloud automatically improves governance
- Relying on administrator testing instead of involving real users
- Underestimating integration complexity
- Decommissioning the source environment before validation is complete
- Failing to assign ownership for migrated projects, spaces and repositories
Many of these mistakes do not cause the migration to fail. The migration completes successfully, users log in and the data appears to be where it should be.
The real problems emerge afterwards.
Reporting becomes harder to trust. Permissions become more difficult to govern. Unused applications continue to consume budget. Teams inherit workflows nobody understands and content nobody owns. The organisation spends months or years managing complexity that should have been removed before migration began.
The most expensive migrations are rarely technical failures. They are governance failures.
Migration should improve the estate. If it merely relocates existing problems, the organisation has paid for change without gaining the benefit.
8. Know when to bring in an Atlassian Cloud migration partner
Not every Atlassian Cloud migration requires external support. A well-governed estate with limited applications, straightforward permissions and clear ownership may be successfully migrated using Atlassian’s own migration tooling and documentation.
However, complexity increases quickly when multiple products, integrations, business-critical workflows and governance requirements are involved.
Consider external support when:
- You have multiple Jira instances or a fragmented Atlassian estate
- Business-critical applications have no clear Cloud equivalent
- Confluence permissions and content ownership are unclear
- Bitbucket is closely tied to delivery pipelines or release controls
- Security, compliance or audit requirements are significant
- Internal teams lack migration experience or available capacity
- The migration timeline leaves limited room for testing or rework
A good migration partner should do more than execute tooling. They should help assess the estate, identify avoidable complexity, rationalise applications and licences, reduce migration risk, validate assumptions and support adoption after go-live.
The goal is not simply to complete the migration. It is to arrive in Cloud with a cleaner, better-governed and easier-to-manage environment than the one you started with.
If your migration involves multiple products, fragmented governance, application sprawl or unclear ownership, reviewing the estate before migration can significantly reduce risk.
Catapult CX helps organisations assess, rationalise and migrate Atlassian environments without carrying unnecessary complexity into Cloud.
9. Atlassian Cloud migration checklist summary
Use this checklist to assess whether your organisation is genuinely ready to migrate.
By the end of readiness planning, you should have a migration scope, an archive list, an app inventory, a user and permissions plan, a test migration plan and named owners for validation.
Before you start
- Confirm which products are in scope. Jira, Confluence, Bitbucket or all three
- Identify source environment. Server, Data Centre. multi-instance or mixed
- Decide what should migrate, archive, retire or be rebuilt
- Assess whether Jira consolidation is needed before migration
Product-level checks
- Jira. Projects, workflows, schemes, custom fields and permissions cleaned
- Confluence. Spaces, permissions, macros, attachments and links reviewed
- Bitbucket. Repositories, permissions, pipelines, keys and integrations validated
- App inventory built; Cloud equivalents confirmed for all critical apps
- App data migration requirements reviewed separately from product data
- Duplicate or redundant apps identified for retirement
Users and security
- Inactive users removed; group structures cleaned
- SSO, MFA and user provisioning requirements confirmed
- Audit log requirements confirmed and preserved
- Public access and data exposure settings reviewed
Testing and cutover
- At least one test migration run before production cutover
- Real users involved in UAT across Jira, Confluence and Bitbucket
- Links, integrations, permissions and app behaviour checked post-migration
- Old estate decommissioned only after validation is complete
Governance
- Named owner assigned for each migrated project, space and repository
- External support engaged if complexity, compliance or capacity makes self-service risky
The most successful migrations leave the organisation with a cleaner, easier-to-govern Atlassian environment than the one it started with. Projects have clear ownership. Permissions are understood. Applications are rationalised. Reporting is trusted. Operational complexity has been reduced rather than transferred.
The practical test is simple. If you cannot explain what is moving, why it is moving, who owns it and how it will be validated, you are not ready to migrate.
FAQs. Atlassian Cloud migration questions
What is Atlassian Cloud migration?
Atlassian Cloud migration is the process of moving Jira, Confluence and Bitbucket from Server or Data Centre environments into Atlassian Cloud. Depending on the environment, this may include users, permissions, workflows, projects, spaces, repositories, applications, integrations and post-migration validation.
How long does an Atlassian Cloud migration take?
The timeline depends on the size and complexity of the Atlassian estate. A small, well-governed environment with limited applications and integrations may take weeks. Larger organisations with multiple Jira instances, complex permissions, extensive Marketplace app usage and business-critical delivery processes may require several months of planning, testing and phased migration activity.
The migration window itself is only one part of the effort. Cleanup, governance reviews, application assessments, testing and post-migration validation often take significantly longer than the technical migration.
How much downtime should you expect during an Atlassian Cloud migration?
Downtime depends on the products being migrated, the volume of data involved and the migration approach selected. A test migration should be used to establish realistic timings and identify any activities that can be completed before production cutover.
Migration plans should be based on validated migration timings rather than assumptions. The goal is to minimise disruption while ensuring the migrated environment can be fully validated before users return to it.
Should you consolidate Jira before moving to Atlassian Cloud?
Assess Jira consolidation before migration, but do not assume it is always required. Consolidation may be justified where multiple Jira instances create fragmented reporting, duplicate workflows, inconsistent permissions, governance challenges or unnecessary migration complexity.
The decision should be driven by operational requirements rather than a desire to standardise for its own sake.
Can you migrate Jira, Confluence and Bitbucket separately?
Yes. Many organisations choose a phased migration approach, moving Jira, Confluence and Bitbucket at different times based on business priorities, complexity and readiness.
However, dependencies between products, Marketplace applications and integrations should be assessed before deciding on a phased migration strategy. What appears independent on the surface may have important links elsewhere in the Atlassian estate.
Do Atlassian migration assistants migrate everything?
No. Atlassian migration assistants support Jira, Confluence and Bitbucket migrations, but product-specific limitations and post-migration checks still apply.
Migration tooling can move large volumes of data, but some configuration items, integrations, application data and customisations may require separate handling or validation.
What data cannot always be migrated automatically?
Migration assistants support a wide range of Jira, Confluence and Bitbucket data, but some elements may require manual handling, alternative migration approaches or post-migration validation.
Examples can include:
- Dashboards and filters
- Webhooks and mail handlers
- Marketplace application data
- Custom integrations
- Repository settings
- SSH keys and app passwords
- Git LFS content
- Legacy macros
- Specialised workflow configurations
The exact limitations depend on the source environment, Atlassian product and Marketplace applications in use. Migration planning should identify these areas before production cutover.
What is the biggest Atlassian Cloud migration risk?
The biggest risk is usually not technical failure.
Most migration tools successfully move data. The larger risk is carrying unnecessary complexity into Cloud, including obsolete content, fragmented workflows, unclear ownership, excessive permissions and redundant applications.
These issues often create long-term governance, support and operational problems after the migration has technically succeeded.
How do you know if you are ready to migrate?
An organisation is typically ready to migrate when it has defined scope, identified ownership, completed estate cleanup, assessed application dependencies, reviewed permissions, planned testing and established a clear approach to post-migration validation.
If those decisions have not yet been made, migration planning is usually incomplete.
When should you use an Atlassian Cloud migration partner?
Use a migration partner when the challenge is no longer technical migration but governance, complexity or risk reduction.
Multiple Jira instances, business-critical applications, unclear ownership, compliance requirements, complex integrations and limited internal capacity are all indicators that additional expertise may reduce migration risk and improve long-term outcomes.
A good migration partner should help improve the estate, not simply move it.
Does this checklist apply to Data Centre migrations as well as Server migrations?
The checklist covers the core pre-migration checks that apply to both Server and Data Centre source environments.
Data Centre migrations have some differences in tooling, architecture and migration scope, so organisations should review current Atlassian documentation for their specific source environment before committing to a migration approach.
