It’s becoming more and more common for companies to find themselves with multiple Jira instances (and other Atlassian tools too). Jira is a very popular tool with teams and there is often a grass roots growth within organisations that means different teams have independently chosen Jira as their tool of choice. Whilst this is a good sign, as it shows there is consistency of thinking and practices within the company, we often find that certain circumstances such as a merger or acquisition, can lead to an organisation having with multiple instances of Jira, which can negatively impact productivity.
While there may be some reasons why having multiple Jira instances is the right thing (e.g. external vs. internal users), typically the best model to enable full optimisation and realisation of all the business benefits of Jira, is to move towards having a single strategic instance. With my clients I've found the three top reasons for this are:
- Improving collaboration and visibility of work. If you want people and teams across your organisation to be able to work on products and projects together, they need to work on a common platform. Having one Jira instance helps enable this superior level of collaboration.
- Reducing management overhead. Although Jira is quite lightweight, there are still some operational overheads to managing it, such as infrastructure and people costs. Having multiple instances creates duplications of this overhead. It’s much better for the service to be managed once, by one team, so the users can focus on their business as usual work and concentrate their efforts on adding customer value.
- License cost savings. It's likely that users have multiple accounts on different Jiras, or that some Jira instances have licences to spare. Optimising here means paying for less licences. Often these savings alone outweigh the cost of migration, creating a win-win situation.
To realise these benefits, it will be necessary to perform a Jira migration and/or consolidation. As there'll be valuable data in existing Jira instances, it’s not as simple as just creating a new one and using that. The existing data and configuration from the different instances need to be merged together. However, there are dependencies that make this process complex and increases the amount of data that needs to be properly migrated. I’ve been doing Jira migrations for nearly a decade now and have recently seen a surge in the demand from my customers. Here are some of the main things I’ve learned:
- Understand the dependencies: a Jira migration is not just about migrating the issues, it’s also about the configuration and these all have interdependencies. For example, a board depends on a filter, which depends on a custom field that depends on an issue type. Understanding the dependencies will inform the order in which things need to be imported.
- Optimise 1st "do I really need to migrate that?": it’s likely that there are duplicate or unused configurations or add-ons. Try to remove these before migration. The less there is to migrate, the easier the migration.
- Know the limitations: there are different methods of import (CSV, Project Import, APIs) and these have different benefits and limitations. Make sure you understand these before starting out so you can choose the best one for your organisation.
- Automate - use curl or python: if you are scripting parts of the migration, use a simple technology, that’s readily available on your organisations infrastructure and with which your people are familiar.
- Test: make sure you test the migration. This is a release like any other and you need to make sure that nothing has been missed or that an existing configuration hasn’t been lost. Ideally you want to make a copy of the target Jira and test migrating into that.
- Ask for help: while it’s possible for your team to figure out the migration on their own, an expert Atlassian solution partner will have the experience, war wounds and successes to get through the process more quickly and cost effectively, with minimal risk.