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 migrations - tips, tricks and advice

Yatish Madhav

Hi all

I know there is a MOVE support channel and the EAP for cloud to cloud Software projects and tons about server to cloud documentation.

But please can you comment here with posts. blog links, suggestions, caveats, etc. about moving / merging cloud instance of Jira to another cloud instance? Eg. if your company merged with another, etc.

What experiences you had, what you looked out for, what problems you facced, etc.

Thank you in advance.

Yatish

Comments

Dave LIAO

@Yatish Madhav - hi Yatish! I moved this question from the Jira Service Management section of Community to the Atlassian Cloud Migration interest group, where I'm sure there will be more useful feedback for you.

Take a look at posts in the group to get an idea of challenges others have faced.

Good luck! 😊

Yatish Madhav

OK great - thank you @Dave LIAO - I thought I did create the project from here

Thank you for the details - I will have a look.

Dave LIAO

@Yatish Madhav - of course, if you have a specific question that hasn't been asked in Community, ask it, and I'd love to try to answer it 😂

Rachel Wright

Hi @Yatish Madhav, here's one to start us off!

You mentioned the use case of one company merging with another and I have the worst of the worst examples to share!

Setting the scene:

Alpha company and Bravo company merge. Both companies have the full Atlassian stack and thus need to consolidate applications. But some team members from Bravo company need access to Alpha's applications right this very second, even though there's no merge strategy and general corporate merge decisions haven't been made.

Creating the mess:

Alpha company uses the username format first.last@alpha.com (or first.last for a Server/Data Center example.) Bravo company uses the username format flast@bravo.com (or flast for a Server/Data Center example.)

New user accounts are created for Bravo users the format first.last and with the Alpha company's domain.

Later, when it's time to do the real consolidation, users end up with duplicate (and sometimes even more) accounts with no tools to merge them.

The result:

Poor user "Mike Jones" ends up with the following accounts in the Alpha applications: mike.jones@alpha.com, mjones@bravo.com, michael.jones@alpha.com, etc.
Users didn't know which set of credentials they should use.
Some users logged in to multiple accounts and created issues/pages/etc.
The admin team had to figure out which account was "the real, go-forward" one, deactivate the others, and help users move data in the few instances that was possible.

Moral of the story:

Decide on a naming convention and stick to it
De-dupe user accounts (in both applications) before attempting a merge. Make sure user accounts are unique to an individual.
- Is mike.jones vs michael.jones one person or two people?
Resist the urge to temporarily add users immediately and "add them for real" in the future
Do anything but this!

I hope this helps someone avoid an obvious but very painful experience!

Rachel Wright
Author, Jira Strategy Admin Workbook

Dave LIAO

@Rachel Wright this 1000%. 💙

It's not why I opened ID-240 many moons ago, but it's one of the reasons I'm particularly fond of it.

Yatish Madhav

Wow, @Rachel Wright - that response seems quite a passionate one on the topic. Thank you for that and the insight on it.

Yeah, I think that is the one baseline that we have set on Atlassian ever since we were on Jira - naming conventions and setting rules around it. We have also had issues with that whole email (and multiple user) issue when we were transitioned from Trello to Atlassian ownership of accounts and again when renaming some of our user emails through our acquisition and email migration. A few cases, but none the less still time consuming to fix.

In the bigger picture of migration, we will definately keep your notes in mind as well. It is much appreciated.

Any other thoughts around moving issues, projects and the bigger monster, Schemes?

Artem Fomin - DevOps Action

- Take both instances to Server.

- Do the user mapping.

- Merge on Server using Botron's Configuration Manager.

- Migrate the merged instance back to Cloud.

You can either use one of the existing sites or (a cleaner approach) spin another Cloud URL.

It might also make sense to have Atlassian Support import the users prior to importing actual data.

No matter what you decide to do, the consolidation process is still highly complex at this time. Hopefully, cloud-to-cloud JCMA will be available soon.

Dave LIAO

I like this answer, as a fan of Botron's Configuration Manager. 💪

Yatish Madhav

Thanks for the comment @Artem Fomin - DevOps Action - So I feel a bit overwhelmed with the migration. I think mostly becuase I dont find much clooud to cloud migration documentation and that we are also relatively new in this ... We moved to Jira cloud just under a year ago. I have never used Jira Server (or DC) before and we need to get the project going ... Tips on that?

Artem Fomin - DevOps Action

There is no straight-forward cloud-to-cloud migration way at this time. A high-level approach is described here: https://support.atlassian.com/migration/docs/compare-cloud-migration-methods/

Your options without spinning a Server instance are limited (you are pretty much stuck with CSV and REST API).

Merging in a temporary self-hosted environment is the most robust approach.

Taking Source to a self-hosted environment and using JCMA is another approach - it's less robust, but is still more robust than CSV/REST API.

Overall, my advice is to outsource this work to experts. There are too many nuances to keep in mind, and just discussing this here won't guide you through all the details.

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-software-cloud

jira-cloud

cloud-migration

jira-service-management