Migrating 15 Years of Company History to Jira

How Bondora moved 15 years of the company’s history from one project management tool to a new one and utilized Jira capabilities to support internal & external processes.

At the end of 2022, our organization set a target to migrate all the company projects and teams from the project management tool we’ve used for the last 15 years, Asana, to Jira. Our end goal was to streamline our operations and eliminate the need for dual-tool usage or constant synchronization between them.

Asana is a project and work management platform designed to help teams and organizations plan, track, and manage their work. It provides a wide range of features and plug-ins that enable teams to collaborate effectively and stay organized.

Jira offers several advantages over Asana, making it a more suitable project management system for larger organizations. Some of the main benefits of Jira include its high level of customization, advanced issue tracking capabilities, support for Agile and Scrum methodologies, integration ecosystem with other tools, portfolio management features, granular access control and permissions management, and extensive reporting and analytics tools. These features allow teams to tailor Jira to their specific processes and requirements while facilitating seamless workflow integration and data-driven decision-making.

In this article, we’ll talk about our approach to this migration, unexpected obstacles, and important learnings on migrating 15 years’ worth of history to Jira.

Starting point & first projects

As we initially approached the project, the decision on which teams from the organization to start with was quite straightforward. We began by working with our product engineering teams and setting up Jira projects for them. The software development process is relatively simple, and Jira was specifically designed for this type of project. Furthermore, many people in our organization already had prior experience with Jira in IT development, making the setup easily understood.

Additionally, we wanted to integrate Azure DevOps so that we can connect our commits to the actual tickets that we are working on. This integration was not available in Asana before.

Our approach:

• Initially, we replicated the setup of the workflows from Asana for five projects/development teams. Later on, we reviewed and aligned the workflows to ensure synchronization across all teams’ development processes. To enhance the process, we incorporated conditions, validators, and post-functions into the workflow.
• We added custom fields (adapted from Asana’s configuration) that varied among different teams but were standardized based on organizational requirements to align processes between teams.
• Additional issue types were implemented to accommodate relevant requests received by product engineering teams from other departments within the company, such as “customer escalation”, “design,” etc. We made a deliberate decision not to utilize sub-tasks in order to avoid potential visibility issues with actual work progress.
• Currently, we use Kanban for software development, which is well-supported in Jira. We might be switching to SCRUM in the future, but this is a point of discussion and alignment.
• Dashboards have been added to Jira, along with reports generated using a Jira plug-in called Great Gadgets. There is a lack of availability of Jira standard reports for Kanban boards. Also, some highly customized reports (such as 95 percentile Cycle Time) are added to Data Bricks utilizing statistical data from Jira.
• One of our primary motivations for implementing Jira was to establish visibility between our development tools and ticketing system. To achieve this integration, we utilized GitKraken’s CI/CD plugin for Jira in conjunction with Azure DevOps.
• Considering extensive collaboration among teams, it was decided to migrate all product engineering teams simultaneously.

The mistake that we made in the beginning was allowing the creation of team-managed projects. Team-managed projects are more suitable for smaller companies with fewer interactions. Those also have limited functionality when it comes to the boards, alignment of the workflows, custom fields, security/permissions, and limitation of usage of some plug-ins. Therefore, in time, all projects were migrated to being company-managed. This is a vital learning point, so make your decision wisely based on company size and ways of working in your organization. The size of our company is around 250 employees with multifunctions, cross-team projects and company-wide goals. We’ve restricted the creation of team-managed projects in our organization, but we still have a few of them that are waiting to be migrated.

Migration tool

Photo by Chris Briggs on Unsplash

One of the first challenges that we needed to resolve was finding a tool/plug-in that would help to migrate (old) tickets’ data from Asana to Jira. We researched different tools available, and the most suitable one that we found was getint.io. It has an easy way of setting up integration between the systems and a user-friendly interface to create field mapping between the systems. An important functionality that we were searching for includes the possibility of migrating comments & attachments from one system to another.

The following factors must be considered for the migration of tickets (archive):

• Licensing cost is per request in case of larger migration, and the price can be costly. In this case, you should also account for the possible length of the project. In our case, it was a 9-month-long project (which in the beginning was estimated to be 5 months). So, think about possible extensions and buffer the time when requesting the license.
• Research and make sure if archive of the tickets is really needed in a new system. Our experience showed that even if the team said that they needed old data in a new system, then going forward, they would not be actually using it, and historical information would be just obsolete in a new tool. This is hard to oversee, but you can start with the migration of only “open” tickets first and then see if the request will come for past data.
• Migration of bigger projects that have a lot of history in the old tool can be time-consuming. Some migrations took over 10 hours to complete. You should account for that.
• Fields:
• Mapping the fields can be complicated between 2 different tools. Fields can have different types. And if, for example, the “string” field type in Asana is mapped to the “date” field type in Jira, data fails to migrate. In this case, we created “temporary” fields for the field’s data to be able to migrate (text field type in Asana should be mapped to text field type in Jira). You can test it on a few tickets and see how it will work in your case. Also, review the fields with the team and decide if the field is actually needed going forward. In many cases, the most relevant information is stored in the “description” field (+ comments, attachments).
• We used additional fields “Asana created on” (date of creation of the ticket in Asana) and “Asana completed” (marks if the ticket was completed in Asana) to be able to navigate the migrated tickets, for example, to move all completed tickets from Asana to “done” status in Jira right after migration.
• Make all fields where data should be migrated “non-mandatory” in Jira first, as this might cause failed migrations (in case those were empty in Asana). Once the migration is completed, you can mark them back to be “mandatory”.
• Make sure you check the hierarchy of the tickets in Asana and how they can be redefined in Jira. In Asana, you have the possibility to have multi-levels of sub-tasks, which is not supported in Jira. We used the approach when the business needed to check those levels, and if the migration of all sub-tasks was needed, then the hierarchy in Asana was changed to have only 2 levels so that all data would be migrated.
• As Asana does not have an actual workflow but has “sections”, which can be viewed and worked on either in a board or list view, sometimes mapping Asana “sections” to workflow statuses in Jira did not make sense. To be able to understand where each section ticket belonged in Asana, we used custom fields that were only relevant for migration purposes. Later on, this field can be hidden or deleted from Jira.

Next teams & Jira advanced administration

Photo by Trent Erwin on Unsplash

Bondora has different functions, including Product Engineering, Data, Analytics, Risk, Compliance, Finance, Legal, People, Customer Support, Marketing, and Office. Each team operates with its own processes and ways of working and has specific needs. Previously, all teams were used to working with Asana and were familiar with the tool’s functionality. However, it is important to note that there are differences in the logic between Asana and Jira. Our main objective was to transition all teams from Asana to Jira in order to streamline our operations and eliminate the need for dual-tool usage or constant synchronization between them.

When the analysis began with the next teams, it became evident that there was a lack of experience and understanding of Jira’s capabilities outside of development projects. Moreover, Jira administration is a complex task that requires both time and expertise to manage effectively. As a result, the decision was made to seek assistance from external consultants to facilitate Bondora’s integration of other company functions into Jira. We reached out to an Atlassian platinum partner in Estonia who provided invaluable support throughout the project implementation process.

The approach we used was taking it team-by-team and conducting analysis, considering the existing setup in Asana, the team’s requirements, and the functionalities offered by Jira to meet their needs. For each team, 1–2 specialists (who played the role of a single point of contact) were identified to gather requirements and provide details of the process.

To streamline and standardize this approach across teams, a template was proposed where all relevant information for the new Jira project could be filled in, such as ticket types, workflows, fields, field configurations, screens, screen configuration, permission schemes, security levels, and automation. Once the initial project setup was completed, testing would be done by the team to identify any necessary adjustments to the project configuration. Finally, ticket migration from Asana to Jira would take place after the setup was finalized.

All projects in the initial setup were configured as Jira Software management projects, as suggested by the consulting company. However, after additional research, we made some changes and converted a few of the projects to Jira work management to better align with the requirements of our teams.

The projects have been fine-tuned through various adjustments, such as modifying fields, workflows, security levels, screens, and adding field values. Additionally, automation was implemented to support processes. The logic behind the new tool needed to be explained, and it continues today.

The main difficulty we encountered was shifting the teams’ and company’s mindset to adapt to Jira’s unique logic, as opposed to what they were used to with Asana. Understanding how the process would differ when working with the new tool compared to the old one was a significant challenge. It is important to note that this task was far from simple, especially considering that Bondora has used Asana since the company was founded in 2008. This was one of the main reasons why we decided to use external expertise to show that Jira has all the necessary capabilities required for different functions within our organization.

Along with the project setup in Jira, we also learned how to administrate company-managed projects in Jira, exploring materials available online, learning best practices, and gaining knowledge and experience with a hands-on approach. Here are some practices our organization uses:

• The naming of configuration schemes should be easy to understand and search for. We use the project key at the beginning of the name of each configuration scheme and configuration to understand to which project it belongs.
• For some teams, Jira work management projects suit them better than software projects. There are some different functionalities available, such as predefined project summary (statistics), calendar view, list view, simplified board view, forms for the creation of the tickets, confluence pages connection and preview in Jira, and the possibility to re-group board, etc. Keep in mind that some of the functionalities of software projects will not be available, such as having multiple boards per project, predefined board filters, quick filters, swimlanes, backlog view, the possibility to view multiple projects on one board, etc.
• If your organization is big enough and you would like to use Jira’s advanced functionalities (such as Advanced Roadmaps, some plug-ins, usage of common flows, custom fields, etc.) as well as align configuration in all projects — do not allow creation/usage of team-managed projects from the beginning as you may create a double-work of migrating team-managed projects to company-managed projects in the future, which is also not a straightforward process.
• Think about who will be the admin(s) of Jira projects in your organization. There should be a limited number of Jira admins who actually understand what they are doing when applying one or another change. As configuration schemes, configurations, custom fields, workflows, and security are shared between different projects, changing one or another may result in unwanted changes to different projects. Still, it does make sense to have a few people who will be Jira admins for them to be able to back up each other in case someone goes on vacation or gets sick, etc.
• It is a good idea to include at least a couple of specialists to deal with the Jira project setup from the beginning so that this knowledge will be shared and the process of implementation will also not stop when someone goes on vacation or busy with other tasks.

Summary and lessons learned

Photo by Isumi Daizy on Unsplash

Changing from one project management tool/ticketing system to Jira and migrating 15 years of history from an “old” tool is a difficult and time-consuming project. Here are the lessons we learned along the way:

• Account for buffer time, as changing the mindset of people to start working with a new tool with a different logic is a complicated and time-consuming process.
• Think through and plan for the migration of tickets from the old system to the new one. Research which tool/plug-in best fits your needs. Also, think of the possibility of leaving the old system for a limited number of users to be able to look into the archive in the old tool. This might eliminate the need for needless migrations and save time & energy.
• Consider hiring experts to speed up the process of onboarding teams to the new tool. They will be able to bring needed expertise and help in speeding up the process of initial project setup and custom configuration. They will also help to share knowledge and train future Jira admins in the organization.
• Have several people from the organization involved in the project from the beginning. This will speed up the project as well as help to obtain knowledge in Jira administration for future Jira admins.
• Google, Google, Google… There is a lot of information on Atlassian products available online, and 99% of the answers to the questions can be found with a quick Google search.
• Do not allow usage of team-managed projects in the case of middle to big-size organizations where all functions should be aligned and working towards common goals. Team-managed projects have limited functionality and better suit small organizations or organizations with independent teams.
• Make the naming of configuration schemas as understandable as possible when you need to search for and re-use them.
• Limit the number of Jira admins as changing configurations unconsciously might result in breaking config in different projects.
• Think through access limitations some teams need to have to handle secure & sensitive information. A good practice is to utilize user groups and not add user-by-user. Create additional user fields to share access to the issues to certain users in case needed.
• Search for available online courses from Atlassian University. Some of the courses are free and could be taken by the whole organization. A good example is Jira Fundamentals, which gives a basic overview of Jira functionality and ends with a 45-minute test with a badge that can also be added to a person’s LinkedIn profile.
• Research and propose plug-ins & features that can help teams in their daily work depending on the tasks they & organization have. We use the following plug-ins, advanced functionality & tools currently:
• Great Gadgets — advanced reports for dashboards.
• Xporter — enables PDF export with a predefined template.
• GitKraken’s CI/CD — Azure DevOps integration.
• Issue template agent & issue templates — predefined templates for issue types.
• Clone Plus — advanced issue cloning.
• Getint.io — integration between ticketing system for migration & sync.
• Jira Advanced Roadmaps — Jira Premium functionality which allows higher-level initiative creation to align, sync & follow teams on company-level goals & strategies.
• Jira Product Discovery — product research & modeling tool for Product teams.
• Jira sandbox — allows testing of different project setups in the sandbox environment.
• Jira ITSD — service desk for internal admins to create & follow on internal IT requests.
• OpsGenie — incident management tool.
• Confluence — organization Wiki.