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

Cloud to cloud migration - First experience

Aaron Williams · 2026-10-23T10:33:16+00:00

* Hi All I wanted to share my experience using the Atlassian Data Transfer tool. Due to a recent partial company sale, we had to transfer 4 Jira projects (3 Team-Managed, 1 Company-Managed) totaling 64GB of data to a new instance owned by the external business. Our source instance is very bloated: 57,000 user accounts,…

Aaron Williams

Hi All

I wanted to share my experience using the Atlassian Data Transfer tool. Due to a recent partial company sale, we had to transfer 4 Jira projects (3 Team-Managed, 1 Company-Managed) totaling 64GB of data to a new instance owned by the external business.

Our source instance is very bloated: 57,000 user accounts, 5,000 custom fields, 300+ work item types, 600+ screens, and 200+ workflows. When you transfer projects to a new site, the tool grabs anything it thinks it might need to ensure an exact working copy. The only things it seemingly doesn't take are automation rules, which you have to export manually.

Because the destination instance was fresh, I couldn't in good conscience let this transfer bloat their site. My solution was to create an intermediary instance to cleanse all unnecessary configs before moving everything to the target site.

The initial transfer to the intermediary site took about 3 hours (estimated at 5 hours). Once in place, I used Claude to help remove all unnecessary users, fields, and groups in just 1.5 hours (doing this manually would have taken weeks). After the cleanup, I guided an Org Admin from the target instance through kicking off the final transfer. Three hours later, it was a success! 🙏 This was all done out-of-hours to ensure data discrepancies were kept to a minimum.

Things I learned:
Don't expect things to go to plan: Transfer failures can add significant time. I wasn't afraid to abandon the first attempt due to a failure, admit it to the external team, and try again the next night. Honesty really works here.

Don't assume everyone knows what you know: Luckily, I met with the external team early on and discovered they did not have a Jira Admin. I tried my best to go above and beyond to explain everything that needed to happen.

Mistakes can happen: I made a schoolboy error - When the projects transferred to the intermediary site I couldn't see any of the work items and panic set in - The issue: I forgot to add myself into the projects 🙄

As for the tool itself, it is very easy to use, but the setup options don't feel granular enough. I just wish it would use the configurations from the selected projects to only take across what is strictly needed—that would vastly improve the experience. On the subject of failures, you are supposed to get a report on what went wrong, but unfortunately, mine was completely blank. 😥😂

Other minor annoyances: All custom fields will have (migrated) added to their name and description. The same goes for project roles which means permission schemes etc get updated likewise. So in my case if I left this when transfering again a custom field would have looked like this "My custom field (migrated) (migrated), not nice for the new owner.

Since I had zero prior transfer experience outside of testing, I feel it went well overall. I'd be interested to hear about others' experiences or if you would have tackled this in another way.

Thanks for reading,
Aaron

Comments

Rebekka Heilmann (viadee)

Great idea to use the intermediary site!

They fixed the (migrated) tag in the JCMA so you'd think they can fix it for C2C as well…

Aaron Williams

Thanks for the lovely comment

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

transfer

jira-cloud-migration