Rally to Jira migration

[Inna S]

Hi, 

I saw a number of posts on the subject with no single relevant answer.

Some old ones refer to solutions that do not exist anymore.

One short video found online is a joke.

So, 

beyond the CSV export from Rally, that would give a file per issue type and would contain the references to the related items, what is the best way to import the data into Jira?

We have stories (several levels of), defects, several levels of portfolio items, test cases and test sets and tasks.

We also have releases and iterations. 

Also there are projects and users, some of them have left the company long ago, but we keep the owner's information on the issues because this helps.

The main issue is recreating relations between related items. 

As we have several years of work in the system, the volume is quite large and the manual linking is out of question.

Any suggestions?

Thank you.

[Brad Peterson]

Hi @Inna S

As you are aware, the CSV export and import method limits the number of issues and is tedious and error-prone, as your volume is quite large. Therefore, using a third-party migration solution is the best way to migrate from Rally to Jira.

Migration projects are typically complex and require careful planning and strategy. The following factors should be considered before undertaking the Rally to Jira migration.

•  Format change: Rally uses HTML for rich text formatting while Jira uses Wiki. So, you need to plan such formats conversion [Like how to convert HTML format to the wiki for the data being migrated]
• Sprint migration with Open State: If Sprints are being migrated, those need to be migrated with Open State until all other issue types are migrated. Finally, Sprint’s status needs to be reconciled as per Jira.
• Loss of entity context and activities: Opt for a solution that migrates the data with history to prevent loss of data.
• Impact on user productivity: Plan the migration in such a way that the user is able to use the system during the migration so that it does have a negative impact on the overall organization operations. 

OpsHub, an Atlassian partner, which has extensive experience in undertaking complex migration projects ensuring zero downtime, no data loss, systematic cut-over, and a factory approach, can be a good choice for the given job. It maintains the relations between related work items, during the migration. It supports the migration of the entities, Portfolio Items, Defect, Task, Test Case, Test Set, Test Folder, User Story, Change Set, Release, Iteration, Milestone, etc., from Rally to the entities, all System & Custom Issue Types, Sub-Task Types, Version and Worklogs, etc. on Jira.

Please reach out to OpsHub’s Migration Experts, for an initial free consultation on migration planning.

Thanks

Brad

[Inna S]

Hi @Brad Peterson , 

thank you for the reference and the tips.

We've already found hard way that while we could use the Rally Excel add-on for export, on a per-project basis, this will still leave us without embedded rich content, like tables and pictures. And attachments are not covered anyway.

We've had a session with the OpsHub and they told us they do not cover import to xRay right now. So I'm not sure how Test Management items are supported.

Then the time frame is huge: we were told our volume would take a couple of months to migrate.

Finally, the pricing is of concern.

So we continue to explore our options.

What I can say for sure is that 'data liberation' is the subject that deserves more coverage in the age of cloud-based services.

[Nic Brough -Adaptavist-]

So there's a couple of things in here that need to be separated out because of the way Jira structures its data.

The main one is that you'll need to consider two types of data - configuration and issue data are separate.

Your issue data is not a problem - it's what the CSV import is for.  One line of CSV per issue, simple.

But most of the configuration data is not importable with CSV (the exception is data in select-list type fields - the CSV import can be told to create new options for select-list fields when it finds it in your CSV.  If, for example, you have a field called "colour" which has options Red, Green and Blue, if the import contains Yellow for an issue, the import can create the Yellow option)

Your issue structure (hierarchy) will need to be created, and you'll need to set up the releases and iterations before you import (although if you do that with "versions", they're a select-list type thing so you can tell the import to create them from the issue data)

But, the good news is that the CSV import can bring in your hierarchy and realtionships.

Jira's base hierarchy is Epic -> Issue -> Sub-task.

If you want to import an Epic / Issue relationship, the best thing to do is import all the Epics first, so that you have issue keys for them, then run a second import for all the Issues.  You add a column for "Epic Link" into that second import, and populate it with the issue keys you have for the Epics.

Sub-tasks are easier, you can do them with their parent issues in one file.  In the csv, you give each issue a unique key of some sort (it gets imported into the "external id" field), and then for each sub-task, you put the unique key of its parent into a parent-id column.

Last you can import "issue links" from CSV as well - see https://confluence.atlassian.com/jirakb/how-to-import-issue-links-from-a-csv-file-in-jira-740262715.html

I think that broadly covers all the different relationships that Jira has, but I don't know if that covers all the different ways Rally might be holding your issue relationships?  Are there others you might need to convert to a Jira relationship?

[Inna S]

@Nic Brough -Adaptavist- 

Rally has more & different relations scheme than what is available in Jira. 

For example, there is indefinite number of story hierarchy possible: story has child stories that have child stories etc.

As a result, a story might have a parent Story AND be related to a Feature.

Then, Defects are also related to Stories. And then Tests.

I could designate the top level Story to become Epic, but then the rest of the hierarchy is lost anyway.

In any case, doing subsequent runs might look like an idea, but only when the numbers are small. I have tens of thousands Stories. Updating the CSV file manually with the newly created Jira IDs is not an option.

Of course, I can code it using the API etc, but it is not fun and sounds like a big effort.

[Nic Brough -Adaptavist-]

I was afraid of that.

Rally was a serious competitor to Jira for a while, for several reasons, one of which was that relationships between issues were easier to use (or understand, at least).  But it  stopped being an Agile tool when CA acquired it and butchered it (the cynic in me says they bought it to stop it stomping all over their products).

The TLDR here is that you are going to need to think about how to set up, and support, your issue hierarchy and linking in a more simple (and hence human usable) way.

I would start (and this his how I've approached dozens of Rally migrations) with

>a story might have a parent Story AND be related to a Feature.

Move these stories to be stories.  With parent Epics, and with the Epics belonging to Features.  (Or flip the names to fit in with SAFe - rename Epics to be Features and Features belong to Epics)

>Then, Defects are also related to Stories. And then Tests.

Defects work well as sub-tasks, unless you're trying to do Scrum with the wrong team.  If your testers are not part of your Scrum team, then raise your defects at the same level as stories. 

>I could designate the top level Story to become Epic, but then the rest of the hierarchy is lost anyway.

If it's an Epic, it's not a story.  You're absolutely right to be raising it outside the story level.