Skip to main content
Illustration of a man and a woman visualizing the data migration journey from Redmine to Jira

How we helped Estonian Ministry of Defence migrate tickets from Redmine to Jira

Alice Bakhoff, Raimo Roots, Külli Solo, Taavi Valgma

In the following article we will examine why Estonian Ministry of Defence needed to migrate their data from Redmine to Jira, what preliminary actions needed to be done and what kind of problems were solved throughout the migration process.



A central IT platform keeps the team on the same page 

„There was a need to limit the number of IT service platforms,“ says Külli Solo, the information manager of the Ministry of Defence about the decision to move data from Redmine to Jira.

„The governing information of the Ministry of Defence, part of what was also in Redmine, lives also in Jira,“ she explains. 

Half a month was planned for the migration process. 

„As a preparation we made sure that test and live Jira instances would be synchronized. We made a full back-up from Redmine and created test users in all the instances,“ says Taavi Valgma, the system administrator of the Ministry of Defence.

„Indeed we planned two weeks for the migration while hoping, that we could perhaps even do it in one week. As it turned out that we started from scratch, having to make decisions and deal with the results on the go, carrying out the migration in one week was not going to happen,“ he states.

„In addition to preparing the systems, I had to grant permissions for the domains and organize a computer for TWN’s expert Raimo. We needed a computer because carrying out the data from the Ministry was not allowed and all work needed to be done on-premise,“ Taavi adds.  

„We could not make any additional preparations, because we did not yet know exactly what could happen during the migration. Visualizing and writing down the key points helped us a lot,“ says Taavi as a sum up. 



Migrating data from external instance to Jira – impediments and solutions

As of Jira 8.4, Atlassian no longer supports built-in importers that are dedicated to specific applications. From Redmine it is still possible to import data to Jira in CSV or JSON format.


Exporting ticket data from Redmine

API endpoint was used to export data from Redmine (in JSON format).

As it turned out that tickets form the API were exported in bulks of hundred, 47 manual savings were made for them. Additionally, data about projects, users and statuses was saved separately.


In order to edit data with Power Query, JSON data is imported to Excel

As the data exported from Redmine did not match the Jira import format, the data needed editing. Power Query that had it’s own nuances was used for that. 

Power Query extends data to new rows, not columns and that creates several entries per one ticket (e.g. each attachment or mark of history is in a new row).

But for Jira, the data needs to be in separate columns (5 attachments means 5 columns, not rows). In order to get data from rows to columns, the data needs to be extended first, then formatted. 

Data is saved to CSV format

Before the final CSV saving it is important to make sure that the encoding of the document would be correct (UTF-8 for the correct Estonian special characters) and that every row would have the caption set.


Attachments are brought from one server to another 

The attachments in Redmine server had different names than on the tickets.

Attachment download links were gathered from the tickets and saved to a text file. Firefox mass downloader plugin enabled to download the number of links, after which the files were saved, zipped and transferred to Jira import folder and unzipped.


CSV import in Jira

An account with administrative permissions was created to carry out the import. This ensured, that all the issues and comments were created by this neutral system account


Data export from Jira to CSV for issue linking

It was not possible to link tickets during the first import because the tickets did not have Jira IDs.

After importing to Jira, all tickets were exported as CSV (export limit was extended temporarily) and the table was split into two sheets. 

In the first sheet we made connections how Jira Key = Redmine ID and then we used this sheet to add a new column for the tickets to describe the connection that Parent ID = Jira ID.

It was also important to check if any ticket was related to several tickets, in case of which the data needs to be in separate columns. 

Finally, an updated sheet that had an issue summary, issue key, links and link type „Redmine linking“ set, was imported to Jira.


Synchronizing Jira and Redmine users

Although many users that were in Redmine also existed in Jira, the system did not connect tickets with their Reporters.

To solve the problem, a list of Jira users was exported to Excel. The list had two columns – full name and Jira username. In the CSV sheet, the full name needed to be replaced with Jira username in case there was a match in the sheet.

Since the ticket history was a big table without projects, statuses and names of the people, all the IDs were replaced with their respective values. Ticket history was then added as a comment, where every entry was marked as a separate comment.  



A successful migration begins with a well-planned strategy

When migrating data from one system to another, it is important that the source data would match the format supported by the destination.

Furthermore, being careful not to lose any valuable data is essential. We advise to check throughout the process that the total amount of data would match the original exported amount of data.  

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.