Acquisitions and the Atlassian Cloud
A client in the governance software industry that frequently acquires other companies came to us with a request to consolidate multiple Atlassian cloud instances, migrate their on-prem Jira Software and Confluence instances, and migrate them from their legacy test management system into Jira Software. Doing this would provide the following benefits:
Having multiple cloud instances, mixed with on-prem instances was causing disconnect and communication issues. By consolidating all of the instances into a single source of truth, the client would benefit from streamlined communications and tasks.
By consolidating the four cloud instances and the single on-prem instance, the client would instantly recognize cost-savings.
Atlassian cloud licenses function per instance so the client was paying for multiple licenses for the same products. The client was also paying for on-prem licenses which made it difficult track and address when at renewal time.
The client was also paying for licenses across the instances, which was bad as many of the apps were duplicates and thus, the client was paying for the same app multiple times.
While the client was already in the cloud, they didn’t want to worry about having to upgrade their on-prem instances and the apps that were installed.
While nothing was wrong with the existing test system itself, it was problematic to try and keep track of testing activities outside of Jira Software and there was no integration between the systems.
By migrating the test management system into Jira Software, the client would be integrated with Jira Software, working from a central system thus, avoiding manually updating tickets in each system, and eliminate the cost associated with the legacy system.
With multiple instances, teams could not integrate their data, tasks and communications when they needed to work with the other teams that had been recently acquired. This led to a lot manual labor, duplicate efforts and ultimately tasks not being completed because they were lost.
The client had inherited (4) other Jira Software and Confluence instances via acquisitions. The client was already using a cloud instance of both Jira Software and Confluence and at the time, Atlassian offered no solution for cloud-to-cloud migrations. To further complicate the engagement, there were on-prem Jira Software and Confluence instances that needed to be migrated to the cloud platform and another requirement to migrate the client away from its legacy, self-hosted test management system to the cloud.
The RenWare Way
In order to account for multiple initiatives and a lack of a tool that would make life easier, our team of experts broke down the work into a more digestible and cost-effective form. Using phases allowed us to deliver the proper solutions and value to the client and provide the executive team with a level of transparency and comfort that a large-scale engagement requires.
Because there wasn’t a tool that allowed cloud-to-cloud migrations to be straightforward, our experts generated and downloaded server-based backups for all Jira Software and Confluence cloud instances. Doing this allowed us to work in our own lab, as we had to leverage the server versions in order to combine the Jira Software instances, which would take several test cycles in order to get the steps down for a successful rollout to what would become the new production environment. Once merged, the team would upload the new Jira Software bundle to the cloud test instance.
It is important to understand that when Atlassian customers have both Jira Software and Confluence cloud instances activated, you cannot simply upload a full backup to Confluence as you could with Jira Software. Therefore, the team uploaded over (300) spaces manually.
A total of (6) test runs were conducted prior to performing the final production run, but the end result was an error free completion of Phase 1 work.
IMPORTANT NOTE: At this time, the Atlassian Migration Assistants did not exist so all work had to be done using the old methods of consolidating instances and uploading them back to the cloud.
By the time this phase began, Atlassian had created a migration assistant for both Jira Software and Confluence. The result was a much more condensed phase as the migration steps were fully automated and much faster than the processes and steps that had to be used during Phase 1. However, because the assistants were still brand new, our experts still performed (3) test cycles to ensure all data, configurations, attachments, history, users, and groups migrated successfully. Once the migration assistants had been fully vetted, the delivery team was able to successfully migrate the on-prem instances into the production instance created during Phase 1. Being able to leverage the migration assistants allowed us to significantly reduce the cost and number of resources required to successfully complete the deliverable for this phase.
The scope of work for this phase was to migrate the client away from their legacy test management system (Targetprocess) into Jira. After providing the client with several test management options, the client settled on TM4J (now known as Zephyr Scale) to satisfy their requirements. The client’s team provided our team with csv exports from the legacy product and we leveraged TM4J’s native import feature. All work was done in the test environment to ensure accurate data transfer and allow time for the client’s team to self-train on the new test management system and how it worked. After receiving final client approval, our team migrated several thousand test cases into Jira Software.
Our expert consultants provided the necessary expertise to consolidate the client's multiple cloud instances for Jira Software and Confluence into a single instance, migrate the on-prem instances to the cloud, and migrate the legacy test management system to Jira Software so all company resources were working from a single tool stack. The client was also happy because our work meant they could eliminate the cost of multiple cloud instances, redundant payments for the same apps, and most notably, the significant cost of the legacy test management system.
While RenWare consultants are not QA experts, they quickly came up to speed with how TM4J works and was able to provide the client with some best practices for this app.
Also, during Phase 2, RenWare met with the client and developed a set of standards and best practices that the client would go on to use in an effort to try and reduce the clutter in their cloud environment, which is important because unnecessary clutter can impact performance and cause negative user experiences.
We used the clients cloud instance that we created during Phase 1 to track all of our work and solicit feedback from the end-users. By using the Atlassian tools, we were also able to reduce the number of meetings with the client’s resources and allowed them to continue to focus on working towards their internal milestones and deliverables.
RenWare has been retained by this client for a few years now as they value our services and expertise around the Atlassian suite of tools.
EVP & CTO
"RenWare was a valuable partner and contributor to the successful completion of our Atlassian initiatives. We were more than happy with their expertise and continue to rely on it as we make additional acquisitions."