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; } } }

What are the biggest challenges you've faced while migrating from Jira Data Center to Jira Cloud?

jameers

Hello Atlassian Community,

Many organizations are planning or actively migrating from Jira Data Center to Jira Cloud to take advantage of Atlassian Cloud's scalability, innovation, and reduced infrastructure management.

While every migration is unique, I'm interested in learning from real-world experiences and best practices from this amazing community.

I'd love to hear your thoughts on the following:

- What was the biggest challenge during your migration?
- How did you plan and execute the migration?
- Were there any issues with apps or Marketplace plugins? If so, how did you handle them?
- How did you migrate custom workflows, custom fields, permissions, and automation rules?
- Did you experience any performance or data migration issues?
- How did you manage user communication, training, and change management?
- What security or compliance considerations were most important for your organization?
- If you could restart the migration, what would you do differently?
- What tools, documentation, or migration strategies would you recommend to others?

From my perspective, some of the common challenges include:

- Assessing app compatibility between Data Center and Cloud
- Managing complex workflows and customizations
- Cleaning up unnecessary configurations before migration
- Preserving integrations with tools like GitHub Enterprise, ServiceNow, and identity providers
- Minimizing downtime while ensuring data integrity
- Helping users adapt to the Jira Cloud experience

I'm looking forward to hearing about your experiences, lessons learned, and recommendations. Your insights could help many teams prepare for a smoother migration journey.

Thanks in advance for sharing your expertise!

Accepted answers

All comments

Brita Moorus

Hi, @jameers 👋 Great question.

From my experience, the biggest DC → Cloud migration challenges are usually:

Apps and Marketplace plugins as not every DC app has a Cloud equivalent, and even when it does, the features sometimes may differ. App assessment should start as early as possible.
Legacy configuration cleanup - old workflows, custom fields, schemes, inactive projects, old users and groups… 🦖 Migrating everything as-is usually makes Cloud harder to adopt.
User and group mapping - especially with multiple directories, inactive users, duplicate accounts, or unclear group naming.
Integrations - SSO, email handlers, REST/API integrations, development tools, BI tools, etc. These often need redesign, not just migration.
Automation and permissions - most configurations migrate quite well with the migration assistant, but I would still validate workflows, permissions, notifications, boards, filters, dashboards, and automation rules carefully after each migration.
Change management - Cloud has different admin, UI, security, and app behaviour. Training and communication matter a lot 💙

What I’d recommend:

run at least one test migration
clean up as much as possible before migrating
assess apps early
freeze major configuration changes before the final migration
prepare a clear user communication plan
validate with real project owners, not only admins

A couple of Community articles/discussions that may also be useful reads:

Top Jira Cloud Migration Challenges and How to Address Them - good overview of practical migration pain points, not just the technical part.
The Jira Data Center Migration Blueprint: 10 Best Practices for Moving to Jira Cloud - useful checklist-style article for planning, cleanup, stakeholder alignment, and testing.
How to Build a Cloud Migration Playbook for Jira and Confluence - nice read if you want a more structured migration plan with responsibilities, timelines, and lessons learned.
Jira Instance Cleanup Guide - not migration-specific only, but very relevant. Cleanup before migration can save a lot of pain later.

Hope these help 💙 Cloud migration is usually 30% tooling and 70% cleanup, preparation, decisions, and communication 😊

Calvin

We did ours with a vendor, and the vendor had done it before so that certainly helped us out a lot.

We did do a lot of clean up beforehand though for all the fields, workflows etc, we took it as a good chance to clean up our system too. We also chose a few key people who were go to amongst teams who were more Atlassian experienced to do testing ahead of time and help other users and do the change management, this helped myself from the Systems team from getting swamped.

A dedicated page (Sharepoint/Confluence) also helped that included basic stuff about the change, cloud UI, youtube videos, who to contact etc. It was sort of lucky the navigation changes came in just before it so Atlassian had a bunch of updated videos due to it that we used as "get started guides" for users.

Security wasn't too bad, but there was the typical assessments, security was harder for marketplace apps though. Particularly ones you can't pin the location of data were big blockers for us. Also we found scriptrunner to not run the same way in data centre.

Regarding issues we had:

Single sign on / access - this was a headache for us being in an organisation level. As I can no longer manage users the same way and getting SSO set up and users was and still is a massive headache. Particularly as we have users in other areas Jiras doing stuff to users that affect our areas jiras users (eg. they disable an Atlassian account as the user doesn't work in their department, but it disables in ours too).
We also had to redo permissions, mapping etc
A weird one, in data centre we would add say 2 projects into a sprint board/filter and it would appear in both projects. In Cloud you have to choose a single location, this stuffed around a few teams that work on single sprint boards across multiple different spaces.
A lot of stuff is moved to an organisation admin. This has been a bit grindy for us as I have to wait for their capacity to make changes, and they don't know if the change is okay to make because only I know why we need the change. Even basic things like seeing upcoming bundled changes and I think even full logs were missing?
Oh and a weird one Confluence had issues, some macros didn't work properly, some images didn't come through. And some weird permissions. I had to manually update some spaces, so keeping the original data centre for a month at least was super helpful. It was also useful because we had users say "this was in data centre I swear" and I could look and see that it wasn't.

I will say though, there wasn't any major issues just things you need to work through.

Oh yeah and two things

No matter how many emails, banners, messages and team meetings telling people we are moving to cloud and here is the new URL someone will still come and ask "What happened to our jira?!?! Where did it go?!?!"
I recommend making your data center read only after the migration. Because guaranteed someone will continue working in there if you don't.

Peter Kerrigan

Agree with everything stated above.

Definitely work with a Partner if you can. Coming from an Atlassian Platinum Parter in a previous life, they've seen almost everything under the sun when it comes to Cloud migrations. Plus, Partners have good relationships with many of the major third-party app vendors; Marketplace apps are often the more difficult piece of migrations, so direct access to support can be a life saver.

Second thing I'd say/echo is the best way to think about migrations is that they're more of a transformation. Regardless of your approach (lift and shift all data and apps, or cleanup on prem then migrate), Cloud is a very different platform with many new/different features. UI/UX differences, third-party app differences, etc.

Don't expect everything to work the same way; users will undoubtedly have questions as they get used to the platform. Echoing @Brita Moorus , good training and communication are key.

Last thing, the team working on the migration deserves some grace. Migrations are hard journeys where you often need to pivot plans as you go through discovery, implementation, and even once you're in Cloud. Be kind to yourself (from someone who tends to be my own worst critic).

Brita Moorus

Great points, @Calvin, especially the part about keeping DC available for a while after migration. That safety net is really useful when users say "I'm sure this existed before" and you need to quickly verify it 😄

Also fully agree on making DC read-only after the final migration. No matter how many emails, banners, and reminders you send, someone will still find the old URL and continue working there 🫠

Dr_ Ankita Mehta-OpsHub_ Inc

Hi @jameers ,

Great question!

One lesson that often comes up is that the technical migration itself can be easier than understanding and simplifying what already exists in Jira.

Many Data Center instances have accumulated years of custom workflows, fields, permissions, apps, and project-specific exceptions. Moving everything “as is” to Cloud can simply recreate that complexity in a new environment. A thorough assessment and cleanup before migration can make a big difference.

App compatibility also deserves early attention. Even when a Marketplace app has a Cloud version, feature parity may not be identical. Testing business-critical use cases early can help uncover differences in permissions, automation, reporting, or integrations before the actual migration.

For complex environments, a pilot migration with a few representative projects can be particularly useful. It provides an opportunity to validate workflows, custom fields, integrations, user provisioning, and reporting before scaling up.

Change management is another area that can be underestimated. Users may see Cloud as “just Jira,” but differences in the UI, administration, and workflows can still require some adjustment. Short training sessions, clear documentation, and a few power users can help with adoption.

If I had to give one recommendation, it would be: treat the migration as a transformation project rather than simply a platform move. Use the opportunity to simplify configurations, retire unused apps, and standardize processes where possible.

For those planning a migration, this article on Atlassian Community also covers several of these challenges and considerations.

Curious to hear what others found most challenging during their migrations, particularly around app migrations and workflow rationalization.

Thanks

David Day: Appcento

Nobody budgets for the cleanup afterwards, we came out of ours with more custom fields than the company had people.

Copies pile up whenever the same source is imported twice, a test instance refreshed on a schedule, phased waves, or several Data Center instances landing in one Cloud site. Removing them by hand is slow because each one has to be checked against screens, field configurations, automation rules and live JQL before it can go.

Order that worked for us: export the field list, sort by base name, group the pairs, check which originals are empty, merge the empty ones first, leave anything with a conflicting schema for review, then delete the copies. If the suffix sits in field descriptions too, raise a MOVE ticket once the values are back in the original, support strips it with a script, and doing that last means the suffix does not disappear with the data still inside it.

Rasmus Ersmarker

David's order is right; the hard part is the verification, not the deleting.

Two facts worth having before a sweep. Atlassian's guardrails article lists "Fields per project: 700", but Pavel V (Atlassian) commented there that the limit "is applied on a field configuration scheme level", and that hitting it only means "Jira admin will prevent adding more fields to the field configuration scheme" — all work items and projects keep working. Support docs add: "Trashed fields don't count toward the 700-field limit." Field Schemes GA retires field configurations and their schemes, and I cannot find what 700 attaches to afterwards documented anywhere — I asked on Atlassian's Field Schemes FAQ thread and have no answer yet.

Second: no Cloud app can read automation rules — no public API exposes them — so that step in your checklist stays manual whatever tool you use. Saved-filter JQL is readable; rules are not.

Disclosure: I build one of the Forge apps in this space — FastAudit ( https://marketplace.atlassian.com/apps/835357462/fastaudit-custom-field-scanner-for-jira ) — so read this as interested. For breadth beyond fields, Optimizer for Jira covers more.

José León

Hello,

If you have a lot of groovy scripts, rewriting them in order to use Jira Cloud can be a pain, because the API is totally different. It maybe useful for you to use TypeScript instead.
Check this plugin, as it embeds Visual Studio Code inside Jira, so you can write your scripts (and custom fields, and post functions, etc) in pure TypeScript:

https://marketplace.atlassian.com/apps/651672896/script-studio-for-jira

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

jira-data-center