Rally to Jira Migration Series Part 3
There are several ways to migrate off of Rally to Jira, but the two most common data migration techniques are Data Sync or ETL.
A data sync is where a third party application is used to migrate data from Rally to Jira. There are a number of integration applications that allow you to data sync, however, when choosing which application to use, you should consider the capabilities of each application and what you need to get out of your migration.
Data can be synced either directionally from Rally to Jira or bidirectionally. You can also sync the data live or historically. In live, everything that is updated in Rally is also updated in Jira. If you sync historically, you can sync all the data from a specific date range.
Data syncs do come with some limitations. Some capabilities and fields may not be supported through the sync and Jira configurations will still need to be deployed manually.
via Third Party App
Syncing with a third party application is very easy because of the visual UI tools. Users don’t need to have any technical knowledge. It’s also easier because it involves incremental loads, meaning after setup, automation keeps everything up to date. The last major benefit is that live sync reduces the downtime of people not being able to access their data.
On the other hand, syncing with a third party application is a little more difficult to set up. The applications are clunky and have limitations. Some systems and custom fields do not allow you to copy over the data from Rally to Jira. The different data types, such as check boxes, radio buttons, and small or large text fields are not clearly defined. These applications also don’t do transformations. If you are wanting to do status mapping, you have to do it one-to-one, making the design of your Jira workflow more difficult to map out.
Some other drawbacks of this method is that licensing costs for third party applications can be costly and you still need to manually configure in Jira. Also, if you need a full data archive for auditing or compliance purposes, this is not the method you should use because you will not be transferring all of your data over.
ETL stands for Extract, Transform, and Load. This means the data will be extracted, transformed so that the new system understands the formatting, and then loaded into the new system.
This can be done incrementally (i.e., a historical data load and then whatever has changed since a specific date can still be loaded to the new system) or phased (i.e., based on business lines, the date of the cut-over, or other business requirements), or as a single lift and shift (i.e., everything from one place to another). With a single lift and shift, you can own the entire process without a dependency on other tools. The scope of data and how it is mapped from one application to the other is custom figured, getting the most complete data set without any data loss.
CSV via Browser App
The next data migration technique is generating a CSV through your browser. This is an easy way to extract data and create reports. However, when exporting, the report file will not include attachments or ticket linkages. In this method, the data will be fragmented so you have to generate separate reports for portfolio items, features and defects. Then you have to take those reports and manually configure them so that they correctly import into Jira. Since this data will not be complete, it will also not be fully functional for an organization’s auditing or compliance purposes.
CSV via Excel Add-in
Another method is to use an Excel Add-In. The great part about this method is the app is free and you can install it into Microsoft Excel. It works similarly to a browser, but you have a more granular querying and scoping allowing you to select specific data. It includes quite a few fields, but not every field is supported and custom fields have issues being extracted out of Excel add-in. Similar to a CSV import, attachments and ticket linkings are also missing from this method.
CSV / JSON Via API’s
The last data migration technique is using CSV or Jason via API’s. In this method, you can tap into the backend of Rally through API’s and download all the data. You are able to access the complete data set, preserving text formatting, system fields, custom fields, attachments, and ticket linking. This method also supports customer transformations giving users more controlling power over mapping out workspaces, field value users, projects, all the hierarchies, and more. One more great feature about this method is users can get their complete data archive for auditing and compliance purposes.
On the other hand, migrating with this method can be difficult because of scripts. You need a developer to help create scripts unless someone already has the scripts. Scripts take time to create and there are additional costs to maintain scripts. However, scripts are likely a one-time operation, so costs will not be ongoing. Also, like the other methods, you still need to do manual configurations in Jira.
Importing into Jira Align
We have established how to import data into Jira, but what about importing into Jira Align? There are three methods to migrate data from Rally into Jira Align.
Directly via Excel
This method seems easy, but it isn’t. In fact it’s a fairly difficult method and is not an intuitive data structure making it cumbersome when trying to create a portable dataset. For each ticket type users have to create a separate file and ticket linkages.
Directly via Jira Align API’s
Migrating through Jira Align API’s is more streamlined, however, it is a fairly new process. API’s are not very robust, don’t support many fields, don’t have graceful error handling, and have limited methods.
Migrating into Jira First and Syncing to Align
The final and most efficient method is to migrate into Jira first and then sync that data to Jira Align through a connector. This method adds another step in the process but provides a more complete and streamlined data set. Users who migrate this way can include more data fields, effective linkages, and encounter an overall better user experience and migration process.
The main things you need to remember when preparing for your migration is that you should only transfer the information that you need. You can always make data available in other areas, but you don’t need to pay the price to have all of it migrated over at the same time.
Then when you start to decide which migration process is best for your organization, remember to factor in each of the limitations. Consider what data you need, what is the best path, do you have enough time, etc.
Migrations from Rally to Jira can be difficult to perform and costly if data is migrated incorrectly. We provide a solution specially tailored for Rally to Jira migrations. Our cost effective data migration technique supports basic migrations all the way to fully custom enterprise migrations. We have three solutions that best fit most migration needs and additional a-la-carte services that ensure you migrate over exactly what you want, how you want it, and with a Cprime guarantee. Migrate with the peace of mind that data fidelity, cost-effectiveness, and security are key tenets to our proven solutions.
For additional reading on Rally to Jira, check out the other blogs in this series.