Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

J CLOUD MA good... J DATA MA better?

Mike Rathwell
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jun 25, 2021

The JCMA is a great tool and does a lot of things. However, is it trying to do too much and be all things to all people?

My scenario that gives rise to this thought:

  • I have a very complex environment; small number of users but does All the Things (JWM before there was JWM)
  • Every trial project migration that is at least moderately successful results in many, many things to fix before it could go live.
  • Years of cruft in the system from predecessors that... meant well... and a special time where Sr. Mgt decided Jira was easy so give all the people admin.

In many cases, I don't want to move a given project as-is. I have several projects that are slated for a scorched earth migration. The intent is to make a new home for them, migrate the data, then move the data into them. Even for the cases where I want to keep the project as-is, there are so many things to fix, often with tedious effort, that it would be easier to build it from scratch in Cloud and... move data into it. That would also allow more pre and UAT testing BEFORE stuff gets cut over and have less cases of a problem creep through because I didn't catch it.

For the most part, especially on the scorched earth migrations, the only thing I want to retain is the data with the highest possible fidelity. The only reason I am using JCMA at all in these cases as that remains the only way to get the data there with the least possible data loss.

I suspect I am not the only person in this situation.

Given this preamble, maybe a JDMA with the following characteristics would be a Good Thing:

  • Choice to move data from source project to <target project> as it's possible that project key may not be the same. Also would allow an easy rationalization of many projects to a single project
  • Fields: Choice to migrate a given field to <field (migrated)> or <field> by using a getObjectByName obviating the need for huge field cleanup every dang time
  • Fields: Choice to create fields not currently in Cloud either based on context OR only create non-blank fields and/or what is in a screen definition if not present on Cloud. This would have the effect of helping rein in out of control global context fields. Would also reduce move errors for fields that don't have an analog type on Cloud.
  • Workflows: Use what is defined for imported issuetype. The one case where a simple fail like JCMA causes is where a getStatusbyName fails OR provide the bits that exist for an issue move IN Jira allowing the mapping of <source status> to <target status>
  • Users: Fine the way JCMA has it but don't error on users that are disabled and have no groups associated (ran into that yesterday)
  • Import: For a given project key, if the source and destination keys match, the choice to delete all current issues and import with the source issue keys intact or new issue keys with simple sequence starting at the next available. 

I can't help but think this would be rather easier to build and make/keep stable than a tool that is trying to do All the Things in an environment as complex as Jira. It's almost the same as the extant "move" or "clone" functions within Jira but knows how to put it somewhere else. If I had one of these, I could literally be halfway done my migration.

Case in point: Yesterday, I tried 5 times to get the beta JCMA that will migrate JSD to JSM to work. The 5th time was the final straw roadblock. In the time I mucked about with it, I could've built the required JSM project, tested it, and simply moved the data in. I would be done, not sitting here with a failed attempt at 1 of 7 JSM projects I need to migrate, and working on 2 of 7.

Even with JSW projects, using JCMA imposes the migration cycle of:

  1. Import the project.
  2. Import the project 10 more times iteratively fixing the things that broke the import attempt, each time cleaning up all the "(migrated)" things because, duh, the Object IDs between two disparate systems don't match.
  3. Import the project 5 more times iteratively fixing the things that made a "successful" migration be borked in real life, each time cleaning up all the "(migrated)" things because, duh, the Object IDs between two disparate systems don't match.
  4. Do the final production migration.
  5. Fix all the things that remain borked and not caught from the "successful" production migration.

If there were a definitive JDMA the cycle would change to:

  1. Build the target project
  2. Test and UAT the target project
  3. Import the data
  4. Production smoke test

I do know there are sync tools that kind of do this but the two I tried had almost as many pitfalls to get working as JCMA does today and they aren't definitively migration tools.

Thoughts anyone?

1 comment

Dave Liao
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Jun 30, 2021

@Mike Rathwell - I'd love a JDMA. Even with standard Jira imports, I end up conducting a battery of imports instead of a single lovely import. 🤷‍♂️

Mike Rathwell
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jun 30, 2021 • edited

That, @Dave Liao 

To my tiny mind, the most important part of the whole migration effort is getting the DATA there with the highest possible fidelity.

Were a clean way to do THAT exist, the solo guy like me could chip away rebuilding function up top and move a project or group of projects at a time chosen to have a given group of humans not have to straddle both hosted and cloud for too long or even at all.

Conversely, if there was a rush, one could reach out to an Atlassian partner with the instructions, "See this here? Make that over there", have a team descend in for a ShipIt party, and then lay in the data on top of the new TESTED and VETTED environment in one fell swoop.

Like Jack Brickey likes this


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events