How to migrate from ADO to Jira

[Hemal Vyas]

Our company is migrating our Agile practice from ADO to Jira. How do we best accomplish this?

[Trudy Claspill]

There are third party apps that you can use if you need to migrate data. Here is a sample search of the Atlassian Marketplace for such apps:

https://marketplace.atlassian.com/search?query=azure%20devops%20jira%20cloud

I have used both products. In my previous company we migrated people and their data from ADO to Jira. In my current company we moved from using Jira to using ADO without migrating data.

You should make sure you take a close look at the functionality differences between the products. ADO allows you to built a many layered structure of parent/child work items. Jira does not natively support that if you are getting the Jira Cloud Standard subscription. In that subscription the default hierarchy is 

Epics > generic issue types > Sub-tasks

...where

Epics are a special issue type with special functionality applicable only to them. They are used to track collections of <generic issue types>. Jira natively recognizes a parent/child relationship between Epics and <generic issue types>

At the <generic issue types> level you have some pre-loaded issue types - Story, Bug, Task. You can define additional issues at this level. In Jira's functionality these are all equivalent issue types. They are siblings and Jira does not natively support making one a child issue of another. The issues at this level are the ones you assign Story Points to and track in Scrum sprints or Kanban.

Sub-tasks are another special issue type. These issues cannot be created independently. They are created only as children of another issue. You can define additional issues that are part of the Sub-task type.

If you want more than that standard hierarchy, you have to pay more to get the Premium subscription where you can add levels above the Epics (like Features and Initiatives), or you pay to add a third party application to your Jira instance that will support extending the hierarchy.

That is just one example of a difference in functionality. 

I would recommend that the team responsible for this migration set up a Jira instance and work with it for some time to become familiar with the functionality, how to administer it, how to customize it, etc. Carefully plan what data, if any, needs to be migrated. Plan for training of your personnel in the differences in functionality. At my previous company the advocates of ADO struggled with adapting to Jira, and took a lot of coaching and support to figure out how to change their processes.

[OpsHub]

Hi @Hemal Vyas 

Data migration is a complex proposition and needs careful planning for its smooth and successful execution. For general pointers, you can look at the blogs, A Guide to Application Data Migration and The Agile Approach to Data Migration. In addition, the following points should be considered before undertaking the ADO to Jira migration:

1) Format Retention: Azure DevOps (ADO) and Jira use different rich text formatting standards which are similar but not equivalent. ADO uses HTML text formatting while Jira uses Wiki markup text formatting. As part of the evaluation phase, you will have to validate such format transformation strategies [i.e., how to convert HTML format to the wiki for the data being migrated]

2) Two-step Sprint Migration: Jira does not let you schedule an issue in closed Sprint. 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 migrated from ADO to Jira.

3) Adaptation to the New Environment: ADO allows for creating a work item hierarchy that is only available for Portfolio items in Jira, specifically for Epic and Deliverable. Understand the model/structural differences and plan out how teams are going to adapt to the new Agile environment.

4) Preservation of Institutional Knowledge: Opt for a solution that migrates the data with history to preserve historical knowledge.

5) Non-disruptive Migration: Depending upon the approach chosen, migration can cause massive disruptions to the operations. Often the cost of disruption can dominate all other explicit and hidden costs. So, factor in the disruption costs in your planning and bias towards solutions that minimize disruption to all aspects of current operations.

6) Impact on ADO and Jira: Jira on-premises would slow down on frequent API calls to add or update data whereas ADO’s user-wise API rate limit can cause frequent hurdles in migrating data from ADO to Jira.

Any migration solution must be able to address these challenges.

7) The following Approaches can be used for migration data from ADO to Jira:

• CSV download/upload: This option is slow, error-prone, and will not preserve comments, attachments, and relationships.
• If a large-scale or high-fidelity migration is needed, then opt for a 3rd party tool. It can help automate migration (scaling it to a large number of work items) while preserving formatting, relationships, attachments, and comments.

OpsHub, an Atlassian partner, has rich experience in undertaking complex migration projects and can help you ease your agile migration journey. We are happy to help in your migration planning process. Please reach out to us for an initial free consultation on migration planning with our solutions architects.

Thanks

[OpsHub]

Hi @Hemal Vyas 

Data migration is a complex proposition and needs careful planning for its smooth and successful execution. For general pointers, you can look at the blogs, A Guide to Application Data Migration and The Agile Approach to Data Migration. In addition, the following points should be considered before undertaking the ADO to Jira migration:

1) Format Retention: Azure DevOps (ADO) and Jira use different rich text formatting standards which are similar but not equivalent. ADO uses HTML text formatting while Jira uses Wiki markup text formatting. As part of the evaluation phase, you will have to validate such format transformation strategies [i.e., how to convert HTML format to the wiki for the data being migrated]

2) Two-step Sprint Migration: Jira does not let you schedule an issue in closed Sprint. 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 migrated from ADO to Jira.

3) Adaptation to the New Environment: ADO allows for creating a work item hierarchy that is only available for Portfolio items in Jira, specifically for Epic and Deliverable. Understand the model/structural differences and plan out how teams are going to adapt to the new Agile environment.

4) Preservation of Institutional Knowledge: Opt for a solution that migrates the data with history to preserve historical knowledge.

5) Non-disruptive Migration: Depending upon the approach chosen, migration can cause massive disruptions to the operations. Often the cost of disruption can dominate all other explicit and hidden costs. So, factor in the disruption costs in your planning and bias towards solutions that minimize disruption to all aspects of current operations.

6) Impact on ADO and Jira: Jira on-premises would slow down on frequent API calls to add or update data whereas ADO’s user wise API rate limit can cause frequent hurdles in migrating data from ADO to Jira.

Any migration solution must be able to address these challenges.

7) The following Approaches can be used for migration data from ADO to Jira:

• CSV download/upload: This option is slow, error prone and will not preserve comments, attachments, and relationships.
• If a large scale or high-fidelity migration is needed, then opt for a 3rd party tool. It can help automate migration (scaling it to large number of work items) while preserving formatting, relationships, attachments, and comments.

OpsHub, an Atlassian partner, has rich experience in undertaking complex migration projects and can help you ease your agile migration journey. We are happy to help in your migration planning process. Please reach out to us for an initial free consultation on migration planning with our solutions architects.