How to Migrate from Redmine to Jira

• Excellent performance – Redmine is known to be buggy, and presents issues when run on certain servers and operating systems. The larger your organization grows, the slower Redmine gets. You'll see a drop in the software's performance, and there's nothing you can do to improve it as your organization grows. With Jira, you won't see these performance issues. Atlassian products have been high-performing since day one, and continue to improve in this area. So, not only is Jira not buggy, there are modifications available that will enhance performance as your demands increase.
• Easy integration with other apps – Jira easily integrates with other apps, whether they’re other Atlassian products or platforms outside of the Atlassian ecosystem. For example, Jira integrates seamlessly with Jira Service Management, Advanced Roadmaps, Bamboo, Hudson, and many others. You simply don’t get this with Redmine.
• Clean user interface – Redmine looks like you’re dealing with something made in 1980. Jira’s layout and functionalities are clean, modern, and easy to- use.
• Better workflows – It’s no secret that Redmine’s workflows are inflexible. Because they’re not particularly customizable, you can only select tasks from start to end. With Jira, you not only have your tasks from start to end, you can also incorporate other actions and requirements for different types of transitions. Additionally, Jira includes a customizable workflow process on a per-project basis; Redmine does not.
• In-depth reporting – With Redmine, there are limited reporting capabilities. Jira, however, gives you in-depth reporting, charting, and graphing, with the choice of running reports on one project, multiple, or all projects.
• Strong online community – Because of  Redmine’s limited online help community, you’re often left in the dark, trying to figure things out by yourself. With the strong, global Atlassian community, you have access to expert support and extensive issue documentation, making it easier to answer your Jira-related questions.  
• Robust add-on marketplace – Redmine doesn't even have a marketplace, and there are limited add-ons available. Atlassian has a strong add-on marketplace, offering many ways to extend Jira's usefulness for your organization.

Atlassian had at one time provided a Redmine Importer app that could connect to a Redmine instance via REST API and import data directly into Jira. Sadly, that app was discontinued years ago after Jira Server 7.13 and is no longer compatible with modern versions of Jira Data Center. 

• Exporting data to CSV files, which may not include all of the data you need to migrate.
• Writing scripts, which leverage the Redmine API in order to extract as much data as possible.

Each path requires a significant amount of effort to modify data into a format Jira can import. Before the import can happen, though, make sure to map your data so you know which elements from Redmine will be migrated into corresponding elements in Jira. Careful mapping will result in a smoother migration.

One major hurdle you should handle before any migration process is the user base inside Redmine. If your Jira instance isn’t new or if the Active Directory (AD) connection you plan to use for Jira isn’t the same as the one used for Redmine, you will need to carefully review the users. If both Jira and Redmine have identical user bases and email addresses, you are in luck! But, in most cases, you will need to do a little user mapping. For example, if you are using different AD connections for Jira and Redmine, you will need to plan a method to bring all users and their associated data over successfully.

It’s a safe practice to evaluate both sets of users from Jira and Redmine. If you are just importing users as is into Jira Cloud, you can skip the user mapping section. But if you are going to sync users from Redmine to their respective Jira user accounts and either the usernames and/or email addresses of the users differ between systems, you will need to work on first setting up a 1-to-1 mapping of the users. This is time-consuming, but very necessary. After you have your mapping set up, you can use that information to update the users as needed. It is best to sync users before the import is performed, which requires some scripts to update all users in Redmine and their associated data.

Some points to note regarding the user import:

• Users who have interacted in Redmine will be created as active accounts in Jira.
• Users who have not interacted in Redmine are placed into a group called “Redmine-import unused-users” and deactivated.
• Passwords are not imported. Imported Redmine users need to have their passwords emailed to them the first time they log in to Jira Cloud.
• If you are using External User Management, users cannot be imported. Instead, you will receive a list of new users that need to be created and added prior to the import.
• If you exceed your user license, the import will stop and you will be given a list of users that cannot be created.

Statuses and Priorities will need to be mapped during the import. So now is a good time to evaluate the statuses and priorities used in Redmine and compare them to the ones in Jira.

Since these are global elements, you may want to consider mapping to what exists in Jira before simply adding all of the statuses and priorities used in Redmine. If you have several statuses and priorities in Redmine that do not exist in Jira, you must determine if it is worth adding more to Jira, or if you can map the Redmine statuses and priorities to what already exists in Jira without cluttering up your system. Be sure to document the mapping before the import. You will need this information for the workflow migration.

Workflows should also be evaluated prior to the import. You will need to get all workflows used in Redmine over to Jira.

Using your status mapping data, you can safely create all the workflows used by Redmine. Ideally, you will rebuild your workflows in the Atlassian platform. If that is the case, you can just add your statuses to the workflow and not worry too much about the steps of the workflow since these steps will change after the import. Just make sure you use all of the proper statuses. If you have just one workflow with all the proper statuses, it should be safe for you to use that for all Redmine projects that you import.

Another time-consuming task is the custom field evaluation. You will need to set up the custom fields used in Redmine in your Jira instance. This process is redundant, but it is best to have all fields set up prior to the import so you can breeze through the mapping of fields during the import.

Redmine “Trackers” are the equivalent of Jira “Issue Types.” Check to see if you can map to what exists in Jira. If not, you will need to create the missing tracker/issue types.

Now is a good time to start setting up the empty projects into which you will import your data. To keep things clean, it is best to set up Redmine-specific schemes to be used during the import process. You can set these up like you would any other Jira project. After you create all of your schemes, go through the list of Redmine projects you plan to import and set up the empty projects with their proper schemes. Do not add components or versions because doing so would turn the empty projects into non-empty projects that the importer can't support. Let the importer handle adding the components and versions.

Since Redmine issues are hierarchical, you will need to duplicate this using links in Jira. You may need to configure a custom issue link to replicate this.

Often when trying to figure out how to migrate, we forget to consider whether to migrate. Not all data is created equally, and it is important to weigh the cost of moving that data against its importance.

Similar to when you move to a new house, it doesn't make financial sense to move items you plan to get rid of.