Best practice when migrating bug trackers


  • QA Engineer

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



  • 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


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2