How to Export Projects from Jira Server to Spira

Migrating User Stories

Firstly, we recommend that you connect your instance of Jira Server to Spira using our existing data synchronization service that will sync artifacts between Jira Server and Spira. This synchronization service is typically used to allow Spira and Jira to work together sharing information, but will also work to migrate the data from Jira to Spira as well:

Once you have completed all the steps to connect Spira to Jira, the synchronization service 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 data synchronization service 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 synchronization service 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 synchronized over to Spira from Jira:

Now that we have dealt with the core Jira artifacts (issues 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 TM4J) or whether they live in an external tool that is separate from Jira (such as TestRail, TestLink, qTest, PractiTest, qTest, 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 TM4J?

If on the other hand, you are using a Jira marketplace plugin such as Zephyr, XRAY, TM4J, 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 synchronization service 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.