November 18th, 2020 by Adam Sandman
Since we published our article letting our users know of Atlassian's plans to phase out and discontinue Jira Server, we have had many Spira users contact us to ask us if they could export their projects from Jira Server to Spira (either on-premise or cloud) and continue working in Spira instead of Jira. This article provides some strategies for migrating the data from Jira Server to Spira as easily as possible. Of course, for those looking to migrate to Jira Cloud, Spira works perfectly with Jira Cloud as well.
Migrating User Stories, Defects and Tasks
Firstly, we recommend that you use our Jira Migration Tool to migrate over the user stories, defects and tasks from Jira. The migration tool consists of an easy to use wizard that allows you to connect to your Jira instance:
and then connect to your Spira instance:
The migration tool lets you map the different Jira issue types to the appropriate Spira artifact type:
Currently, the following artifact types in Spira can be mapped to Jira issues: - Requirements (used for user stories, features, epics, etc.) - Tasks (used for tasks and sub-tasks) - Incidents (used for all other issue types such as bugs, defects, issues).
The migration wizard will automatically create a new project in Spira to hold all the artifacts with the same name as that used in Jira.
Migrating User Stories and Other Requirement Types
The migration tool will automatically bring over all the user stories, epics, features, and other requirement issue types in Jira into Spira. For example, a sample user story illustrated below:
will automatically appear in Spira with the same name, description, reporter, assignee, comments, attachments, component, and any mapped custom properties/fields:
Once all of the requirements have been seamlessly migrated into Spira, you can use the different views to see them in the exact same way that you would in Jira. For example, if you are familiar with the list views in Jira, the Spira sortable list view will give you the same information:
If you prefer the Jira board views, then you can use the built-in Spira Planning Board to get the same Scrum and Kanban boards in Spira that you are used to:
If you would like to take advantage of some of the unique requirements views in Spira that are not in Jira, you can just click on the requirements view selector to use those additional options:
- Requirements hierarchical view
- Requirements mind map
- Requirements document view
Migrating Issues and Defects
At the same time as the user story migration, the migration tool will also bring over any other issues from Jira as incidents into Spira. For example, a bug in Jira that looks like this:
will be migrated over to Spira as shown below. The migration tool will bring over the issue's name, description, priority, release, component, attachments, developer comments, and any other mapped custom properties/fields.
Once all of the defects/bugs have been seamlessly migrated into Spira, you can use the different views to see them in the exact same way that you would in Jira. For example, if you are familiar with the list views in Jira, the Spira sortable list view will give you the same information:
If you prefer the Jira board views, then you can use the built-in Spira incident board view to get the same Scrum and Kanban boards in Spira that you are used to:
Releases and Versions
At the same time that requirements and defects have migrated over, the corresponding Releases and Versions will also be migrated over to Spira from Jira:
Tasks
Any of the Jira issue types that are mapped to tasks in SpiraTeam:
Will be imported into SpiraTeam as types of task:
You can take advantage of the other Spira task views, including the Task Board and Task Gantt chart.
Now that we have dealt with the core Jira artifacts (issues, tasks and releases), the next aspect to consider are some of the data managed by add-ons:
- test cases from an external test management tool or from a Jira marketplace plugin
- source code managed in Git / Bitbucket.
Migrating Test Cases
The process will depend on whether your test cases are currently being managed as a type of issue in Jira by a third party plugin (such as Zephr, XRAY, or Zephyr Scale) or whether they live in an external tool that is separate from Jira (such as TestRail, TestLink, qTest, PractiTest, etc.). We shall cover each of the options separately.
Migrating from a 3rd Party Tool Like TestRail, TestLink, or qTest?
If your test cases and test runs are currently being managed by a third-party tool, then the best option will be to look at the list of pre-built migration tools that we have for Spira:
Each of these migration tools will be able to seamlessly move the test cases, test sets, and associated test results from the tool directly into Spira. Once that is done, you can then connect the imported test cases, test sets, and test runs with the requirements and defects already migrated in directly from Jira.
For example, if you are using qTest, the migrated test cases, and test sets:
would be migrated over as follows:
As another example, if you are using TestRail, the migrated test cases, and test sets:
would be migrated over as follows:
Migrating from a Plugin Like Zephyr, XRAY, or Zephyr Scale?
If on the other hand, you are using a Jira marketplace plugin such as Zephyr, XRAY, Zephyr Scale, or TESTFlo, then your test cases will be stored inside Jira as a custom issue type. In this case, there is a two-step process to bring these over into Spira. Firstly you would map those Jira issue types to be a requirement type in Spira. That way the migration tool will bring over those test cases as a type of requirement in Spira:
Then, you can use the Tools > Create Test Cases feature to convert these requirements seamlessly into Spira test cases:
Now you can then link these created test cases with the appropriate requirements, user stories, defects, and other artifacts in Spira. Unfortunately, you won't be able to migrate over the execution history using this process, but you will get the key test case data:
If you would like to bring over the test execution history, then you can just use our Excel import utility that would let you bring over the test cases, test sets, and test runs seamlessly from Jira and its plugin. You would just need to export the test cases, test steps, and test runs from the Jira plugin into a CSV or Excel format first:
What About the Source Code?
The last piece of the puzzle is to migrate the source code from Jira and/or BitBucket into Spira. This part is actually easy, assuming that your source code in Jira Server is stored in a BitBucket Server Git repository (or any Git repository in fact), you can just use the standard Spira Git integration to connect your Spira projects to different Git repositories:
Then you can browse the source code folders and files, and view the revision history of each file:
and use the new cool inline code DIFF viewing tools to see the details of each set of code changes directly in Spira:
Once that is done, you can then either keep using BitBucket Server or switch to a cloud Git platform such as TaraVault, it's entirely up to you.
Summary
So if you are a Jira Server customer and currently considering your options, you have two paths forward with Spira and Inflectra:
- If you want to keep using an on-premise solution, you can seamlessly move from Jira Server to Spira as discussed in this article
- If you migrate from Jira Server to Jira Cloud, all of your existing Spira integration continues to work seamlessly.