This is the second part of the two part series on making the switch from a Open Source issue tracker to JIRA, our commercial issue tracking tool. You can read part one (how to move) here.

To find out what it's actually like to make the switch, I spoke with Preston Tollinger, who made the move about a year and a half ago.

Preston is CTO of Cellfire, a US-based mobile software company that allows consumers to access coupons and deals from brand-name merchants nationwide, through their cell phone. Preston founded Cellfire in 2005. It has since grown to support over 800 different mobile devices, and is available on all US carrier networks.

Preston, when you founded Cellfire, you started with Mantis and MediaWiki. Then about a year later, you switched from Mantis to JIRA, and from MediaWiki to Confluence. What prompted your switch to Altassian tools?
We switched to Confluence first. That was pretty easy, as the internal Wiki champions all wanted Confluence to begin with. For JIRA, it was a little more involved. We had clearly outgrown Mantis' capabilities. In particular, we wanted to have custom workflows, and several different issues types. At the time, Mantis couldn't support either of those. We also wanted to add custom fields, another feature Mantis lacked.

How did you approach the switch to JIRA?
Slowly. When we started the switch, our developers were big fans of Mantis. To show them the difference, I setup a test instance of JIRA, adding some custom fields. Then I let the developers play with that for a while. In most cases, they saw the advantages pretty quickly. There were a couple of die-hards who wanted to stay with Mantis, but the majority was quickly on-board with the change. Honestly, had I waited for 100% buy-in, it just wouldn't have happened.

Did you immediately start to take advantage of JIRA's customisations, such as workflows, and custom fields?
Exactly the opposite. I took a long time, about six months, to slowly start to use JIRA's process tools. We started talking about the possibilities immediately, but only made changes very slowly. Initially, the only people using Mantis was our small group of developers, so the first switch was to simply move them. Then, over time, we began to use JIRA's customisations to add more rigor to our development processes, and to open JIRA up to other internal users.

How are you using JIRA today?
We now track all releases in JIRA, and use Confluence to generate all our Release Notes. Marketing keeps an eye on development, and uses it to manage their own projects, such as when we do a specific release for a customer.

We couldn't have done any of this in Mantis. We need new fields and new workflows, all of which JIRA provides.

How do you manage JIRA customisations? Is it centralised?
No, quite the opposite. Lots of people have the rights in JIRA to create and modify fields, workflows, etc. Everyone knows & agrees to only change their own stuff. And, frankly, if something really went awry, we can always restore from a backup. As a startup, we've got a small IT staff, so if we tried to centralize all this, it just wouldn't scale.

Has there been any downside?
The only management issue has been trying to keep the total number of projects to a reasonable count. Initially people added new projects for what was really subparts of another project. This made it harder for people to organize and find data and people felt a little overwhelmed. Once we merged a few together and dropped out the ones not being used things have been running smoothly.

Do you use any other Atlassian tools?
We're using Confluence, Bamboo and Clover, and Crowd connected to Active Directory.

Thanks Preston!

Have you made the switch from Open Source to JIRA? Let us know the details!

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

Loren Davie, on Twitter (@LorenDavie):

Thanks, Loren!

Here's what a couple of other people have been writing about JIRA lately.

First up, Julien Ponge writes about using Git & JIRA together to handle patches:

So here is how it goes for those cases: I create a branch for each pending patch. The naming convention that I use is damn impressive: pending/JIRA-ID. Say that I need to work on IZPACK-163: I create a branch called pending/IZPACK-163.

Julien is writing primarily about managing an Open Source project in his post, but his advice is useful to anyone who needs to deal with patches that don't get shipped out right away.

Next, Jamie Echlin gives a couple ways to set JIRA issue security level by issue type

It's not possible in JIRA to create an Issue Security Scheme by issue type. For instance, you may want that defects should default to Private, and enhancements should default to public (or none). You might expect that issue type security scheme would be a mapping of issue types to issue security schemes (in the same way as Field Configuration Schemes), but unfortunately not. There are two ways to get round this, one using Javascript, one with a post-function.

Jamie writes about JIRA quite a bit at http://blogs.onresolve.com/, so be sure and check the whole thing out.

What have you been reading lately?

Atlassian is pleased to announce the release of JIRA Studio 1.5! The release features an upgrade to Confluence 2.10, improvements to searching, the ability to close issues via Subversion commit logs, and more!

Upgrade to Confluence 2.10

The Confluence team recently released version 2.10 and we've updated JIRA Studio's Wiki to that release. With the Office Connector, a part of Confluence 2.10, you can view, import and embed Office documents directly in your Wiki pages. And the new widgets macro makes it easy to embed multi-media content from other web sites. Full details are in the Confluence 2.10 Release Notes.

Search Improvements

We've added QuickNav, which displays relevant search results right below the search box as you type. As soon as you see the result your interested in, just move down and select it.

Close issues via Subversion commit messages

We've tightened the integration between Subversion and JIRA, allowing you to close a JIRA issue the same time as you commit a change. In the Subversion commit log, simply refer to the JIRA issue ID and include one of the new Action Commands. You can log time against an issue, add an issue comment, or move the issue through it's workflow, all from the Commit log!

Balsamiq Mockups for Confluence

Here at Atlassian, we use Balsamiq Mockups a lot. It's a great tool for creating quick, meaningful screen mockups, perfect for those times when a picture really does replace a thousand words. With this release of JIRA Studio, we've added support for Balsamiq for Confluence, so you can see for yourself. Read all about Balsamiq at the Balsamiq Plugin Page and get the details on how to add Balsamiq to you JIRA Studio instance on the Plugin Policy page

And More!

Full details on this release of JIRA Studio are available at the 1.5 Release Notes.

And, please, let us know what you think.