Often times, we’re asked about switching from an Open Source Issue Tracking tool to Jira. This 2 part series will first look at the tools available to help you switch, and then we’ll have a Case Study from a customer who made the switch.
This time, let’s talk about the “how“: How do you make the switch?
Conversion Tools
Let’s start with data migration. Jira ships with data converters for both Bugzilla and Mantis., and they work in the same way: after setting some configuration parameters in the Jira Administration pages, the importers read the data in the original issue tracker, and write the data into the Jira project(s) you specify.
If you need to convert from Trac, Denis Dzyubenko wrote an Open Source tool you can use. Read about Denis making the switch on his blog, and grab the converter itself from Google Code (browse the source tree to find the scripts.)
If you’re using Redmine, BugTracker.NET, or one of the other Open Source bug tracking tools for which there is no dedicated converter, you still have options, including the CSV Importer, Jelly Scripts, or using RPC.
Complete details on these converters are available on the Migration from other issue trackers page in the Jira Documentation.
Using a converter
The basic process for using the Bugzilla, Mantis or generic CSV converter is pretty much the same: launch the converter from within Jira, use a Wizard to identify the source data & set any options, and import.
For example, with the CSV importer, after starting the Wizard and pointing it at the source file, you need to setup mapping so the conversion tool knows how to move the data. Input fields can be mapped onto existing Jira fields (click all these images to zoom in):
Or you can create a new custom field during the import process, and map your existing data onto the new field:
In addition, for fields with static lists like “Resolution” or “Status”, you can map the values in the input data onto existing values in Jira, or create new values where needed:
There are five steps in all in the CSV importer, including the ability to save an import configuration. Once everything is set, start the import, and wait for the import result report:
Managing the Conversion Process
But the mechanics of moving are only part of the equation. When and how you switch matter, too.
A change in issue trackers changes the daily workflow of everyone who uses it. It’s not something you want to spring on your developers as a surprise. It requires upfront planning, and agreement from the users on the very idea of switching.
A few suggestions:
- Take some time up front, and get some consensus. Consider setting up a test environment before making the real switch over, and give your users a chance to play with Jira, and get to know it. Get their input and feedback on how best to configure the fields and workflows in Jira — after all, they’re the ones who will use it the most.
- Beware of making too many changes at once. Just switching tools can be a lot for users to get used to. The day you migrate to Jira is probably not the day you want to completely upend your development processes. In fact, you can use Jira’s customisation features to setup a workflow that matches your existing tool, and make the switchover that much less painful for your users.
- Another option is to start new projects in Jira, but leave existing projects in your current tool. Then, over time, migrate projects over as it makes sense. This is exactly the approach The Apache Software Foundation has taken. They put Jira in place a while back, and continue to use both Jira and Bugzilla, depending on the needs and wants of the project.
- Consider getting some help. We’ve got a number of partners who can help you with both the planning and logistics of the switch. Matt Doar at Consulting Toolsmiths, Gianugo Rabellino at Sourcesense, and Dave Pickering at New Aspects are three guys who have done this kind of work in the past. And you can find a long list of partners who specialise in Implementation on our Partner Speciality Page
Next Time
Next time, we’ll hear from a customer who moved from Mantis to Jira. You can read that article here