The Jira Data Center Migration Blueprint: 10 Best Practices for Moving to Jira Cloud

[#1]

The shift to Cloud

In our previous article, Which Jira Cloud Migration Approach is Right for You?, we explored the different ways organizations can move from Jira Data Center to Jira Cloud and how to choose an approach based on scale, complexity, and business needs.

Cloud migration is a deadline-driven business decision. Atlassian has confirmed that Jira Data Center will sunset by 2029, forcing enterprises to move to Cloud. Industry studies

consistently show that nearly 70–80% of large migration programs exceed timelines or budgets, most often due to disruption, data gaps, and rework during execution.

Building on that foundation, global enterprises are increasingly moving to Atlassian Jira Cloud to benefit from managed security, automatic updates, elastic scalability, and reduced infrastructure overhead. Atlassian’s long-term Cloud roadmap has further reinforced Cloud as the strategic destination for most organizations. 

The stakes

For large Jira instances, migration is not a simple data transfer. It is a transformation program that affects users, workflows, reporting, governance, and business continuity. Millions of issues, years of historical context, and deeply customized processes are often involved.

The reality check

Success isn’t measured just by reaching Jira Cloud-it’s measured by how little teams are interrupted along the way.

This blueprint outlines 10 proven best practices to help enterprises migrate from Jira Data Center to Jira Cloud with minimal disruption, no downtime, preserved data richness, and predictable outcomes.

1. Perform a comprehensive data audit and preserve data richness

The principle: garbage in, garbage out

Before migration begins, conduct a thorough data audit. Identify obsolete projects, unused custom fields, redundant workflows, and outdated configurations. Migrating unnecessary data increases cost, risk, and complexity.

Preserve what actually matters

Critical Jira data goes far beyond issues and fields. It includes:

• Comments and comment history
• Attachments and embedded images
• Issue links, dependencies, and hierarchies
• Traceability across projects and tools

These elements carry context that teams rely on daily.

The hidden cost of data loss

When data richness is compromised, teams lose historical insight, traceability breaks, and audits become harder. The impact often surfaces months later when it is too late to fix.

2. Conduct a rigorous add-on assessment

Apps behave differently in Jira Data Center and Jira Cloud. Even when an app is available on Cloud, its data does not automatically move during Jira migration

Create a clear decision matrix

For every add-on, decide whether to:

• Keep – The app is needed and has a Cloud version
• Retire – The app is no longer needed
• Replace – A different Cloud app is required

Plan add-on data migration separately

Add-ons like test management tools store their own data. This data is not migrated by default and requires separate planning, tooling, or manual steps to avoid data loss.

Practical tip

The Jira Cloud Migration Assistant (JCMA) helps identify whether an add-on is compatible with Cloud, but it does not migrate add-on data. Business-critical add-ons need a dedicated data migration plan. For business-critical add-ons, teams often rely on platforms like OpsHub Migration Manager to plan and execute add-on data migration alongside Jira.

Add-on compatibility and add-on data migration are two different steps, and both must be planned for a successful Jira DC to Cloud move.

3. Choose the right migration approach

Simple migrations need simple tools

For smaller Jira instances with limited customization, Atlassian’s native tools or scripts may be sufficient.

Complex migrations need Enterprise-Grade Tools

Large environments often involve:

• High data volumes
• Custom workflows and schemes
• Phased project moves
• Parallel operations
• Strict uptime requirements

In such cases, an enterprise migration platform is equipped to handle scale, complexity, and no downtime.

4. Keep teams working during migration

For large, distributed teams, Jira is central to daily work. A 24–48 hour shutdown impacts multiple time zones, disrupting issue updates, approvals, incident response, and release coordination. Work continues offline, leading to manual tracking, duplicates, and rework once Jira is back.

Extended downtime often results in delayed releases, growing backlogs, and confusion as teams temporarily work outside Jira. As organizations scale, the operational and cost impact of these gaps becomes increasingly significant.

Avoid the “Big Bang” freeze

A phased co-existence approach allows teams to continue working in Jira Data Center while data migrates to Jira Cloud in the background.

Rather than requiring a full system freeze, enterprise migration tools from Atlassian Silver Solution Partners like OpsHub enable source-active migrations, where Jira Data Center remains operational while data is incrementally moved to Jira Cloud, minimizing disruption to teams.

5. Maintain access to reports during the transition

Reporting often breaks mid-migration

During migrations, Jira data is split for a period of time-some projects run on Jira Cloud while others continue on Jira Data Center. This separation disrupts anything that relies on cross-project data, including dashboards, saved filters, and management reports.

Teams commonly encounter issues such as:

• Dashboards showing incomplete or misleading results
• Filters returning fewer issues than expected
• Reports that previously spanned multiple projects no longer working

While individual projects may function correctly, visibility across teams and portfolios becomes fragmented.

Plan for unified visibility during the transition

During Jira Cloud migrations, teams often operate in both Jira Data Center and Jira Cloud at the same time. To maintain visibility, reporting should be designed to pull data from both systems instead of relying on a single Jira instance.

This is typically achieved by using a central integration layer that synchronizes key work items and status information across environments.

Without unified visibility:

• Status reporting becomes manual and inconsistent
• Decision-making slows down due to missing or partial data
• Oversight is reduced at the exact point when changes are more

Maintaining reporting continuity during migration prevents loss of control while the Jira landscape is confirmed across environments.

6. Minimize setbacks with built-in failure recovery

Things will fail. Plan for it

In large Jira DC to Jira Cloud migrations, temporary failures are expected. Network interruptions, API throttling, and partial data transfer issues are common especially when migrating millions of issues across multiple projects.

Design for recovery, not perfection

A resilient migration approach should support:

• Automatic retries that resume from the exact point of failure
• The ability to continue even when migration requirements change mid-way
• Automated data verification and reconciliation after retries
• Centralized visibility into failed items, without requiring manual log analysis

Enterprise-grade migration platforms are designed with these scenarios in mind, helping teams recover quickly from transient failures without restarting entire migration waves or impacting timelines.

7. Transform data to fit Jira Cloud

Cloud works differently from Data Center

Jira Cloud enforces different configuration models and best practices. Workflows, issue types, and custom fields that evolved organically in Jira DC may not translate cleanly or optimally into Cloud.

Adapt data as it moves

Rather than migrating legacy structures as-is and refactoring later, it is far more effective to transform data during migration. This can include:

• Mapping legacy statuses to streamlined Cloud workflows
• Consolidating or restructuring issue types
• Aligning projects to Cloud-ready templates and governance models

Migration solutions that support in-flight data transformation allow teams to shape data to fit Jira Cloud standards during the move, reducing post-migration rework and ensuring the Cloud environment is usable from day one.

8. Start with a pilot migration (Wave 0)

A pilot migration is not meant to prove that data can move; it is meant to expose what will break at scale.

Select a small but representative set of projects that reflect real-world complexity, including:

• Different workflow models (simple and heavily customized)
• High and low attachment volumes
• Active integrations and automation rules
• Projects with reporting and compliance dependencies

Use the pilot to validate:

• Configuration fidelity: Workflows, schemes, permissions, and notifications behave as expected in Jira Cloud.
• Data integrity: Issue history, comments, attachments, links, and timestamps are preserved accurately.
• Reporting continuity: Dashboards, filters, and cross-project visibility continue to work as teams expect.
• Day-to-day usability: common actions such as transitions, updates, and searches perform reliably.

Findings from the pilot should directly inform migration sequencing, data transformation rules, and support planning for subsequent waves.

Involve migration stakeholders early

The pilot should involve migration stakeholders who own outcomes, not just approvals. This includes Jira administrators, process owners, reporting owners, and representatives from active delivery teams.

Their role is to:

• Validate that Jira Cloud supports existing operational needs
• Identify gaps that require configuration changes or data transformation
• Confirm that reporting and governance expectations are met

Early stakeholder involvement reduces late-stage surprises and creates alignment before larger teams are moved.

9. Scale the migration in controlled batches

Don’t move everything at once

After the pilot, avoid migrating all teams in a single rollout. When too many projects move together, small issues become hard to diagnose and fix. Moving in batches keeps problems contained and easier to resolve.

Group projects that can move together

Create batches based on practical readiness, such as:

• Business impact: Move less critical projects before mission-critical ones
• Team readiness: Start with teams that are comfortable adapting to change
• Support capacity: Ensure help is available when teams move

This reduces pressure on both users and support teams.

Pause, fix, then continue

After each batch:

• Check that data looks correct
• Confirm reports and dashboards still work
• Review early user feedback

If something isn’t right, fix it before moving to the next batch. This step-by-step approach keeps the migration predictable and avoids compounding issues.

10. Focus on post-migration support

The first two weeks matter most

Most challenges appear as soon as teams start using Jira Cloud for their daily work. Users notice differences in workflows, permissions, notifications, dashboards, and automation almost immediately. If these issues are not addressed early, teams slow down, lose confidence in the system, and begin raising repeated support requests.

Early support helps teams adjust quickly and prevents small usability issues from becoming long-term blockers.

Provide structured support

Post-migration support works best when it is planned and visible, rather than reactive.

Effective post-migration plans include:

Dedicated support channels
Provide a clear place where users can ask questions and report issues related to the Cloud environment, such as a specific Jira project, Slack channel, or service desk queue. This avoids confusion and ensures issues reach the right owners quickly.

Virtual office hours
Schedule short, recurring sessions where users can raise questions in real time. These sessions are especially useful for resolving common issues like workflow changes, permission differences, or reporting adjustments.

Guidance on Cloud UI changes and feature differences
Share simple explanations of what looks different in Jira Cloud, what behaves differently, and what functionality has changed or moved. This reduces guesswork and helps users complete routine tasks without unnecessary trial and error.

Together, these steps help teams settle into Jira Cloud faster, reduce frustration, and stabilize productivity soon after migration.

Conclusion: Migration is a program, not a one-time event

Migrating from Jira Data Center to Jira Cloud is not a single cutover; it is a structured change program that unfolds over time. It affects how teams work, how data is trusted, and how business continuity is maintained throughout the transition.

Organizations that succeed treat migration as an ongoing initiative, not a deadline-driven task. They plan for phased execution, ensure data is reshaped to fit Cloud, prepare for inevitable failures, maintain visibility and reporting during transition, and invest in post-migration support that helps teams stabilize quickly.

In large and complex environments, this level of control often requires enterprise migration platforms such as OpsHub Migration Manager (OMM), designed to support phased moves, parallel operations, data fidelity, transformation and scale without forcing teams to stop work.

Ultimately, a successful Jira Cloud migration is defined less by how fast teams move and more by how consistently work continues before, during, and after the move. Thoughtful planning-not speed alone is what makes the Cloud transition stick.

[Artem Taranenko]

Great article! A big piece that feels understated is the incompatibility of DC automations and scripts, especially third party (Power SIL, ScriptRunner Groovy) and external (leveraging API) with Cloud.