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:
- Import the project.
- 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.
- 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.
- Do the final production migration.
- 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:
- Build the target project
- Test and UAT the target project
- Import the data
- 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?
