I am working on migrating from a 14 year old in-house bug tracker to MantisBT. I see the new bug tracker as a way to get more organized about our dev, QA, and project management processes. Ideally, I would like to migrate all our old bugs into a single Mantis project (For example, a project titled 'Legacy items'), and start fresh with new projects and only move over the most recent items from the legacy items.

But, now that I am getting pushback from my coworkers to modify Mantis to look and behave more like our old bug tracker, I don't see the point of migrating as I feel that our processes will not change.

Should I push back myself to start somewhat completely fresh with Mantis? What would be the best rationale?

What is the best accepted practice when migrating bug trackers?

What is the best way to deal with a coworker who's main objection is that they can't see a list of items that have changed in a project by version number by release instead of by individual build (Even though Mantis comes with a Change log which is essentially the same thing)?

  • Would it be an option not to migrate the old tickets, but use them parallel until the old ones run out? Starting the new tracker only for new projects? May 15, 2014 at 6:28

3 Answers 3


Whenever I see something like this I start to think "it depends" on many things. What are your expectations for the migration? What are your coworkers expectations? Do they mesh? What is your intent going forward? It's hard to really say what the best practice is, without really know what you hope to achieve with this.

My experience in this area has been:

  • I migrated because the old system did not allow me to do X, where X was a feature or process that I could not live without going forward either due to the projects we were doing or the Testing/Tracking I was doing.
  • Migrating usually means a new interface, and perhaps there is pushback because what you are giving your coworkers is more complex, it no longer meshes with their workflow so they want what did work before. Can you adjust it to mesh and still have a cool new tool? Probably if you have a configurable system
  • When I have done migrations I have done them as either A) An entirely new system, forget all that old debt, we don't want it anymore! or as B) This new system gives us a whole lot of capabilities, but we still want to be able to review the older defects for tracking or reporting or historical reasons. So I put in what was necessary
  • Did you train? Obviously this is a new system, either your coworker is unaware of how to get what he wants, or is unable to customize his view to get what he wants, maybe you can show him?

Typically I have two goals when moving to a new system in Testing

  1. I am improving the process, procedures or reporting in some way and this new tool gives it to me
  2. I have buy-in from everyone concerned, and if they have concerns I get them ahead of time and make sure the new system can handle those issues, or if it cannot find how to meet my "customers" halfway. They give a little, and so do I. After all, every other group was a customer of mine and I needed to keep them happy, so I had their buy-in

I don't have a good answer about best practices, but can share some experience-

An in house bug tracker was replaced by another in house bug tracker. the new tool was totally redesigned from the floor up. During the transition we made an effort to close most of the old bugs, the important once were migrated and the less important once were left at the old tracker, soon after the old tracker became read only until it was taken down about a year later.

Another project migrated from Trac to Jira, the entire database was (slowly) migrated. The entire look and workflow were redesigned and reviewed.

My thoughts ? this could be a good opportunity to look back and discuss the pros and cons of your process, user interface, the information included in bug reports, reports etc. Work from the top down- start by convincing your management first and get their support, and then ask your colleagues for their inputs, this might help with getting more productive inputs.


Several tips based on experience:

  • First, design your new process for bug tracking. Then, adapt the new tool to implement that process. It's fine to keep the old process, but this is a good opportunity to tweak/improve since you are changing anyway. Involved a few people from various roles (dev, test, PM, leadership) to get all points of view.
  • Take this opportunity to clean out old bugs. You may have 14 year old bugs that haven't been worth-while fixing. No need to migrate those. Invest some time in cleaning up the old list of legacy bugs.
  • Be bold with the change. Not everyone will be 100% happy, but if they have ways to get the information (like you described), then they will adapt. Don't let a few minor glitches get in the way of the big change.

Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.