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

Great question having done several Server to Cloud migrations, here's what consistently works: Before you start: * Run a full audit remove unused projects, old users, broken workflows. Migrating junk just moves the problem to Cloud. * Check every app against the Atlassian Cloud compatibility list. App gaps are the #1 cause of migration delays. During migration: * Always do a dry run first in a staging environment. Never go straight to production. * Use the Jira Cloud Migration Assistant (JCMA) for the bulk of the work but don't rely on it alone it won't handle everything. * Migrate in waves start with a low-risk project, validate, then scale up. After migration: * Validate data integrity immediately: issues, attachments, comments, custom fields, permissions. * Keep the Server instance in read-only for at least 2 weeks as a safety net. * Re-test all automations and integrations they often break silently. The biggest risk most teams underestimate is identity mapping — especially if you use LDAP/AD. Sort that out early. Happy to answer any specific questions we've handled migrations of all sizes at Citala Technologies.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Jordan Collins_z62xaw

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

Accepted answers

All comments

Benjamin_tmh9yg

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 P 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

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 🤠 ☀️

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

@Trudy P 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

Support Application

Great question having done several Server to Cloud migrations, here's what consistently works:

Before you start:

Run a full audit remove unused projects, old users, broken workflows. Migrating junk just moves the problem to Cloud.
Check every app against the Atlassian Cloud compatibility list. App gaps are the #1 cause of migration delays.

During migration:

Always do a dry run first in a staging environment. Never go straight to production.
Use the Jira Cloud Migration Assistant (JCMA) for the bulk of the work but don't rely on it alone it won't handle everything.
Migrate in waves start with a low-risk project, validate, then scale up.

After migration:

Validate data integrity immediately: issues, attachments, comments, custom fields, permissions.
Keep the Server instance in read-only for at least 2 weeks as a safety net.
Re-test all automations and integrations they often break silently.

The biggest risk most teams underestimate is identity mapping — especially if you use LDAP/AD. Sort that out early.

Happy to answer any specific questions we've handled migrations of all sizes at Citala Technologies.

Evie Z.

@Support Application

Hi there,

The external links in your post have been removed per our Atlassian Partners - Rules of Engagement. Partners may only link to the Atlassian Marketplace or Partner Directory–external site links are not permitted.

Thank you for your understanding!

Ammara Amir

Did a Jira Server to Cloud migration last year for a mid sized team, so sharing what actually worked for us.

Best practices, start with a clean up before you migrate. Archive old projects, remove inactive users, and review your apps and plugins because not all of them have a Cloud version. This one step saves you a lot of headache later.

Common risks to watch for, custom workflows sometimes don't carry over cleanly, attachments can fail silently if your instance is large, and user permissions occasionally get reshuffled. Always run a test migration first on a sandbox Cloud site before touching production.

Atlassian's Jira Cloud Migration Assistant is honestly the most reliable route. It's built for this and handles users, projects, and issues well. Just don't rush it, run it in stages if you have multiple projects.

For data integrity, compare issue counts, attachments, and user lists pre and post migration. Pick 10 to 15 random issues and verify comments, history, and attachments manually. Sounds tedious but catches problems early.

Downtime depends on size but for most teams it's a weekend job. We did ours Friday evening to Sunday and users were back Monday morning without issues.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud