Server to Cloud Migration – What Are the Best Practices for Jira Cloud Migration?

[Jordan Collins]

Hi community,

I’m planning a server to cloud migration for Jira (Cloud) and want to understand the safest and most efficient approach before proceeding.

I would like to ask:

• What are the recommended best practices for migrating Jira Server to Cloud?

• Are there any common risks or data loss issues I should watch for during migration?

• Is using Atlassian’s migration assistant the most reliable method?

• How should I verify data integrity after migration is complete?

• What is the typical downtime expected during a production migration?

Any advice, checklist, or real-world migration experience would be very helpful.

Thank you in advance!

Jordan

CEO, Caribbean Nest

[Benjamin]

Hi @Jordan Collins ,

You'll need to evaluate your instance first to determine the amount of risk and the timeline needed to accomplish the task. Every server to cloud migration is different from one to another. Most of the issue stems from Apps. The more Apps and data you have , the more complexities there are. Not every app is supported on cloud and not every app on cloud has every capability that was on server. 

To verify and identify the down time neccessary would come down to testing rigorously and having a UAT.  Once you run a test migration several times consistently, you should have a good idea how long it will take. Also, having a thorough UAT will help idenitfy the major problems. It's one thing to see you have the same number of spaces and work items, but it another thing if your workflows, dashboards, and reports are working the way they should.

Here's a high level guide to get you started:

https://www.atlassian.com/migration/plan/cloud-guide#introduction

-Ben

[Trudy Claspill]

Adding to this...

Disclosure: I work for Praecipio, an Atlassian Platinum Solution partner that has a specialization in Cloud Migrations.

If you have concerns about the migration process due to lack of experience with it, then you may want to consider engaging with an Atlassian Solution partner. I provided a link to the partner directory in my first statement above. Many partners, including Praecipio, can engage to the depth of assistance you think you need. For instance, you might engage a partner to do just the Cloud Migration Readiness Assessment, to help you evaluate the risk areas in your migration.

At Praecipio we have done many Cloud migrations for companies of all sizes and all degrees of mission critical data. If you are interested in the services we can offer (if we serve your geographic region per the partner directory) please fill out the Contact Us form on our site and our team will reach out to you.

[Arkadiusz Wroblewski]

@Trudy Claspill 

Agree, Solution Partners have Huge Expertise when you don´t have Specialist on Board in Company.

[Dr_ Ankita Mehta-OpsHub_ Inc]

Hi @Jordan Collins

Welcome to the Community!

A few things worth keeping in mind during a Jira Server → Cloud migration:

• Define the migration scope first. Decide whether the plan is to move the entire instance or only selected projects. Large environments often work better with phased migrations.
• Check app and configuration compatibility. Some Server apps, workflows, or custom fields may not behave the same way in Cloud, so reviewing these beforehand helps avoid surprises.
• Jira Cloud Migration Assistant (JCMA) is Atlassian’s recommended starting point and works well for many standard migrations. More complex setups sometimes require additional planning.
• Verify data after migration. Compare issue counts, attachments, comments, and user mappings between the source and target to confirm that everything transferred correctly.
• Plan for downtime during final cutover. Depending on the instance size and data volume, it can range from a few hours to longer.

In your case, you may also want to explore an Atlassian Solutions Partner and an enterprise-grade migration tool, OpsHub Migration Manager (OMM) .  (Listing on Atlassian marketplace) It supports both phased and full migrations while preserving historical data such as comments, attachments, relationships, and field mappings. Many teams also use it to avoid downtime and reduce disruption during the move. Sharing this here from the perspective of an Atlassian Solutions Partner in case it helps with your evaluation.

You might want to look at this Jira DC to Jira Cloud migration listing on Atlassian marketplace for more information. 

Also, these articles on the Atlassian Community can be helpful references:

1) Jira Cloud: New Tool Adoption Steps - Atlassian Community

2) Which Jira Cloud Migration Approach Is Right for Y... - Atlassian Community

3) The Jira Data Center Migration Blueprint: 10 Best ... - Atlassian Community

All the best!

Ankita

[Olga Cheban _TitanApps_]

Hi @Jordan Collins !

We recently went through a DC-to-Cloud migration ourselves for Smart Checklist (our own solution for Jira), and we documented the whole experience in a case study. There are the real challenges we hit, how we solved them, and a reusable migration playbook.

Might be worth a read as a hands-on complement to the official Atlassian docs: From Data Center to Cloud (Forge): Smart Checklist migration case study

I hope this helps!

[Arkadiusz Wroblewski]

Hello @Jordan Collins 

for Server → Cloud the safest approach is basically: assess → test → repeat → cut over. Every migration is different, but most problems are predictable (apps + identity + permissions).

Best practices (what actually works):

Do an assessment first: clean up what you can (unused schemes, old projects, broken configs). Less data = faster + fewer surprises.

Apps first, always: inventory every app, decide replace / migrate / retire, and confirm what data can be migrated (this is where most migrations fail).

Run multiple test migrations into a test Cloud site and do real UAT (not only “counts match”): workflows, permissions, dashboards, automations, integrations, JSM portal (if you use it).

Freeze changes for the cutover: agree on a change window (no config changes, no workflow edits, no app changes right before go-live).

Common risks / data loss

App data: some apps don’t have a Cloud equivalent or don’t migrate data 1:1.

Users & identity: email mismatches, duplicate accounts, group conflicts, wrong product access.

Permissions: “it migrated” but people can’t see what they should (or worse, can see too much).

Integrations: anything relying on Server IDs, custom scripts, or direct DB access will need rework.

Is Atlassian’s Migration Assistant the most reliable?

In most cases: yes. It’s the standard, supported path and gives you pre-checks + a predictable support story. The key is: it’s a tool, not a strategy — your testing and app planning matters more than the button you click.

How to verify after migration

Do it in layers:

Counts: projects, issues per project, users/groups, attachments (spot check), key custom fields.

Functionality: workflows/transitions, permissions, filters/dashboards, automations, SLAs/queues (JSM).

Real scenarios: pick 5–10 daily workflows and run them end-to-end (create → triage → transition → report).

Downtime expectations

There’s no universal number. The only reliable way is:

run test migrations until the duration is consistent

use that as your baseline for production + add buffer Apps and attachments usually drive the timeline.

Have a great Day 🤠 ☀️