Jeff Leyser

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):

csv-field1.png

Or you can create a new custom field during the import process, and map your existing data onto the new field:

csv-field2.png

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:

csv-value.png

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:

csv-completed.png

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


2 Comment(s)

I'd be interested to know if any folks have converted from Serena TeamTrack to Jira successfully.

Thanks!

By Dan at January 16, 2009 3:56 AM

From my point of view, the biggest problem with the current release of JIRA is its
incapacity to receive a full history of existing tickets from another tool (not
simply the latest current snapshot).

Why ? Simply because of bugs (registered in JIRA JIRA since 2004) that prevent
to properly create a comment in the past, to apply a workflow action in the
past and so on.

To migrate GNATS databases and keep full PR history, I have chosen Jelly
scripts (but the problem would have been the same with RPC) and had to fix that
bugs and also improve existing jelly tags on my own.

By Yves at January 16, 2009 8:51 PM

Post a comment





Remember personal info?

Type the characters you see in the picture above.