TBC Bank is a leading regional financial institution and an early adopter of enterprise-scale Agile and Atlassian practices. At migration, the bank operated two large Jira Data Center environments supporting more than hundreds of software engineers and operational teams.
When TBC Bank began its Jira Service Management Cloud journey, migrating Assets data posed a major challenge. Atlassian's migration tools for Assets were still evolving, and no proven method existed to preserve complex Assets schemas, object structures and relationships during migration.
For a financial institution of this scale, accepting data loss or rebuilding Assets manually was not an option.
To solve this, TBC Bank adopted Insight Assets Backup & Migration - one of the first dedicated solutions for Assets backup, recovery and Cloud migration.
We spoke with: Nika Melikidze Atlassian Ecosystem Expert | Platform Governance & Cloud Automation | Atlassian Community Champion | TBC Bank and Tako Galogre Certified Atlassian Administrator | Product Owner @ TBC Bank | PSM I | PSPO I
about their migration journey, the challenges of moving Assets to Cloud in the early days of Atlassian Cloud adoption, and lessons learned from one of the region's pioneering enterprise migrations.
Q1. Three years ago, when you started planning your Cloud migration, what was the state of Assets migration capabilities available in the Atlassian ecosystem, and what challenges did you identify early?
- When we started planning the migration, moving Jira itself to Cloud was already becoming a more established topic, but Assets was a very different challenge. At that time, the available migration capabilities for Assets were still developing, and there was no mature, proven path that gave us enough confidence that complex schemas, objects, attributes, relationships, and historical context would be preserved exactly as expected. We did initially explore native migration approaches. They were possible, but for an Assets environment of our complexity the process was significantly more complicated and did not give us the result we wanted. One important limitation for us was that we risked losing historical information about how the data and objects had changed over time. Our schemas also contained references across multiple levels, in some cases extending through a large part of the overall Assets structure. This meant that even a migration that successfully transferred individual objects could still create problems if references or relationships were changed or lost. That was when we realized that Assets could not simply be treated as another part of the Jira migration. It needed its own migration approach, testing cycle, and validation criteria.
Your Jira environments supported more than 250 software engineers and 20 operational teams. What role did Assets play in your daily operations, and why was preserving that data so important?
- Assets was already an important part of several operational and service-management processes across the organization. Its value was not limited to storing individual objects. Different processes relied on the information, relationships, and context maintained within Assets, and we were also already using Assets data in automation. Because of this, losing or incorrectly migrating the data could have affected processes that depended on it. Preserving the structure and relationships was therefore just as important as preserving the individual objects themselves. At our scale, manually rebuilding or validating everything after migration was not a realistic fallback. We therefore treated Assets data integrity as a critical migration requirement rather than an optional improvement.
Q3. When evaluating migration approaches, what were the key requirements you needed a solution to meet before trusting it with your Assets environment?
- Our evaluation criteria were driven primarily by risk. The first requirement was data completeness. We needed confidence that objects and their attributes would arrive in Cloud without unexpected gaps.
The second, and probably even more important requirement, was relationship preservation. Our Assets schemas included references across several levels, so transferring individual objects without accurately preserving those relationships would not have been enough. We also needed the process to be repeatable and testable. We performed many test migrations before the production move, which allowed us to validate the outcome, identify differences, and repeat the process when necessary. Backup and recovery capabilities were also important. The solution provided backup capabilities as part of the migration approach, which gave us an additional level of confidence while testing and preparing for the final migration. Finally, we wanted an approach that allowed us to validate the Assets migration independently rather than discovering issues only as part of the larger Jira Cloud migration. Insight Assets Backup & Migration provided that practical path and allowed us to build confidence progressively before the final move.
Q4. Looking back at the migration project today, what aspects of the migration process proved most valuable, and what surprised you most during execution?
- Looking back, one of the most valuable parts of the process was being able to treat the migration as an iterative exercise rather than a single production event. We performed many test migrations. Each iteration gave us another opportunity to compare the resulting Cloud environment with Data Center, identify differences, and improve the next migration attempt. This was particularly important because our Assets schemas contained references across several levels and, in some areas, relationships spanning a significant portion of the schema. Successful migration therefore meant much more than confirming that the expected number of objects had been transferred. Performance was also a challenge at the time. Cloud migration capabilities were still relatively new, and both the Atlassian ecosystem and the available migration tooling were evolving while organizations like ours were already attempting migrations at enterprise scale. We also encountered configuration differences between Data Center and Cloud. Some identifiers, keys, and system-generated values behaved differently between the two environments. These were not necessarily major issues individually, but at scale they reinforced why repeated testing and detailed validation were necessary. The broader Cloud migration also reinforced the importance of having a dedicated migration team, regular coordination, monitoring, and enough time for repeated testing. Our overall migration journey ultimately took longer than the initial plan, but that additional time allowed us to solve issues properly rather than accept unnecessary risk simply to meet an original timeline. One of the biggest lessons was that a migration tool can automate the movement of data, but the organization still needs to define what a successful migration actually means for its environment. For Assets, that means validating not only the data itself, but also the relationships and the processes that depend on it.
Q5. Today, Cloud migrations have become much more common. Based on your experience as one of the earlier enterprise adopters, what advice would you give to organizations preparing to migrate Jira Service Management Assets to Cloud?
- The first recommendation would be not to treat Assets as just another Jira configuration item. Before migrating, understand which parts of your Assets environment are truly business-critical, which relationships must be preserved, and which processes depend on that data. Second, define your validation criteria before starting the migration. Object counts alone are not enough. Attributes, references, relationships, automation, and dependent processes should all be considered when determining whether the migration was successful. Third, test repeatedly with representative data. In our experience, multiple test migrations were one of the most important parts of building confidence. The goal of testing should not simply be to prove that a migration can complete successfully, but to discover differences while there is still time to address them. Organizations should also understand their backup and recovery options before the production migration rather than considering them only if something goes wrong. Finally, be prepared for differences between Data Center and Cloud. Even when the same concepts exist in both environments, identifiers, system-generated values, configurations, or behavior may not always map exactly one-to-one. Cloud migration capabilities are significantly more mature today than they were when we started our journey, but the underlying principle remains the same: the migration should be driven by data integrity and business continuity, not simply by completing a technical transfer.
