How to Migrate from Redmine to Jira

If you’ve been using Redmine for project management and issue tracking, you’re undoubtedly aware that this tool has quite a few limitations. You’ve probably also heard that Atlassian’s Jira is the number one development tool for agile teams and that it has a reputation for being able to improve a team’s performance at every step of the development process. Unfortunately, migrating from Redmine to Jira is not a quick and simple task. This raises the question: is it worth the bother to switch to Jira? Based on our experience in the field, the answer is a resounding “yes!” Here are some of the reasons why. 

Benefits of Jira vs. Redmine

• Excellent performance – Redmine has been known to be buggy and present issues when run on certain servers and operating systems. And the larger your organization grows, the slower Redmine gets. You’ll see a serious degradation in the software’s performance, and you won’t be able to do anything about it. With Redmine, you’ve got the product and that’s what you get; there’s not much you can to do improve performance as you grow.
• Jira provides excellent performance without any of these problems. Atlassian has been strong in performance since day one and continues to grow 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 from the Atlassian product suite or from other platforms. For example, Jira provides great integration techniques for integration with Jira Service Desk, Atlassian’s Portfolio (another reporting tool), 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 functionality are clean, up-to-date and easy to use.
• Better workflows – It’s no secret that Redmine’s workflows are terrible. Because they’re not particularly customizable, all you can do is choose tasks from start to end. In contrast, with Jira you can not only have your tasks from start to end, but you can also flow in other actions and requirements for different types of transitions. In addition, Jira is also very customizable on a per-project basis; Redmine is not.
• In-depth reporting – With Redmine you’re very limited on the reports that you can pull for issues and projects. Jira gives you in-depth reporting, charting, and graphing, with the choice of running reports on one project, multiple projects, or all projects.
• Strong online help community – Because Redmine’s online help community is so limited, you’re often left hanging in the dark, trying to figure things out by yourself. With Atlassian’s very strong community backing and extensive issues documentation, resolving questions with Jira is quite a bit easier.
• Robust add-on marketplace – Redmine doesn’t even have a marketplace per se, and a very limited choice of add-ons is available. Atlassian has a strong add-on marketplace, with many options available that can extend Jira’s usefulness to your organization.

Preparing to Migrate from Redmine to Jira

User Mapping

One major hurdle you should handle before any migration is the user base inside Redmine. If your Jira instance is not a fresh and empty install or if the Active Directory (AD) connection you plan to use for Jira is not the same as the one used for Redmine, you will need to take extra care reviewing the users. If both Jira and Redmine have identical user base 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 safe practice to evaluate both sets of users from Jira and Redmine. You should determine if all users need to be imported as is. If you are just importing all users as is into Jira, you can skip past the user mapping section. But if you are going to sync users from Redmine to their respective Jira user accounts and either the user names 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 can be a little 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 get the users in sync before the import is performed. This will require 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 will be placed into a group called “Redmine-import unused-users” and deactivated.
• Passwords are not imported. Imported Redmine users will need to have their passwords emailed to them the first time they log in to Jira.
• If you are using External User Management, users cannot be imported. Instead, you will receive a list of new users that will 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

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 worthwhile 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 with unnecessary items. Be sure to document the mapping before the import. You will need this information for the workflow migration.

Workflows

Workflows are another area of concern that must 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 paradigm. If that is the case, you can just add your statuses to the workflow but 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 to be imported.

Custom Fields

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 can be a bit redundant, but it is best to have all fields set up prior to the import. This allows you to breeze through the mapping of fields during the import.

Tracker / Issue Type

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

Schemes and Projects

Now is a good time to start setting up the empty projects into which you will be importing all this 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 for any other Jira project. After all of your schemes are created, go through the list of projects you plan to import from Redmine and start setting up the empty projects with their proper schemes. Do not add components or versions, because doing so would turn the empty projects into nonempty projects—and the importer cannot be run for nonempty projects. Let the importer handle adding the components and versions.

Links

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

Migrating from Redmine to Jira

At this point you should be in a safe place to begin the import. Hopefully, you are doing this in your Development Environment first and making plenty of backups. In fact, now is a good time to make one more backup before the import.

Before you can start the import you must first make sure you are an admin in both Jira and Redmine. Then enable the REST service in Redmine, or you will not be able to connect for the import.

Once you are properly prepared, the migration itself is straightforward. Here’s what you need to do:

1. Get connected – Connect to Redmine through Jira.
2. Map the projects – You will be prompted to map the projects from Redmine to Jira. You will have three options: Create a project, Map To, or Do Not Import. Since you already set up your empty projects, you can easily map from Redmine to Jira.
3. Map the custom fields – Since all of your custom fields are set up at this point, just find the matching fields in the drop-down and map them out. There have been bugs reported when the importer creates the custom field versus when you manually create them prior to import. Save yourself the struggle and create them first!
4. Map other fields – After you complete the custom field mapping, you will be prompted to choose to map fields such as priorities. Trackers and statuses always get mapped. During this step, you will also need to select the Redmine workflow that you already configured in Jira.
5. Map the values – This can be a lot of clicking and selecting, but if you did all your prep work, it should go smoothly. This is where you get to refer to all your mapping documentation and map out priorities (if selected in the previous step), issue types, statuses, and such.
6. Map the links – The last step before the import runs are mapping out the links which you should have already configured. Once this is mapped out successfully, you can start the import.
7. Do the import – If you are not importing every project that is in Redmine, you may see errors during the import due to links between an imported and not imported project being broken.
8. Save the configuration file – After the import runs, SAVE YOUR CONFIGURATION FILE! This comes in handy so you don’t have to go through all the mapping again.
9. Review your logs – Check for any errors or issues.
10. Repeat as necessary – It may take a few sweeps to get everything imported as expected. But since you are in your Development Environment with plenty of backups, this should not be an issue.

Conclusion

While migrating from Redmine to Jira is a significant project that requires careful planning and preparation, the project is well worth the effort. Once the migration is complete you’ll have a project management and bug-tracking tool that’s superior in all ways—performance, reporting, user interface, workflows, extensibility, and online help community.

Of course, if you need help making this migration happen, give us a call. As an Atlassian Platinum Solution Partner, Praecipio has extensive experience with the entire Atlassian product line.