Maintaining multiple cloud and on-prem instances was causing a disconnect between teams and communication issues with management. By consolidating all of the instances into a single source of truth, the client would immediately benefit from streamlined workflows and communication to the various management teams and stakeholders. Creating and viewing dependencies between work items and teams would become easier and thus, would make the boards, dashboards, and reporting more accurate.
Maintaining multiple cloud and on-prem instances not only makes things more difficult for the teams, but it is a nightmare of Atlassian administrators to maintain and adds additional headaches at renewal time. The client was submitting multiple renewals to their finance team, which caused outages because the finance team believed they had already taken care of the renewal.
By having multiple cloud and on-prem instances, the client was actually paying multiple times for the same Atlassian marketplace apps. If you know anything about the Atlassian platform, you know that app licenses can be expensive because they are attached to the number of users listed in the Jira and Confluence licenses.
While the client had cloud instances, they still had to worry about upgrading their on-prem instances. This was listed as a significant pain-point because the upgrades never went smoothly. The upgrade process was so challenging that the client stopped upgrading the instances which then means they were not taking advantage of new or enhanced features. Management teams often overlook the cost, time, and effort that come with upgrading which when they go wrong is even greater on these indicators.
While the legacy test management system worked for the client, it was not integrated with the Atlassian tools. Also, it could only be integrated with a single instance so what was the client to do with all of the other instances? This increased the manual effort to properly track and link test cases to Jira issues and also caused significant duplication. The licensing structure for the legacy test management product was also costly, so the client wanted our team of certified experts to review and propose a solution that would reside under their Atlassian environment with better integration and functionality.
With multiple instances, teams had to manually pull data from the various systems in an effort to provide management with an overall view of the business initiatives. However, many times there were gaps in their charts and data due to the decentralization of the the data. This led to requesting bloated budgets or not requesting enough budget, which made the CFO and other management teams being upset and presenting the wrong information to their customers.
At the time of this migration, Atlassian did not offer an automated migration solution--the Jira and Confluence Cloud Migration Assistants did not exist.. Luckily, our team of certified experts were familiar with the "ole skool" approach and generated the necessary server-based backups and downloaded them into our RenWare lab. Using our lab means there is zero impact to the client. They don't have to spin-up and maintain one-off test instances, which the client really appreciated. Using our internal migration processes, we implemented five test runs to ensure we captured and resolved any migration issues prior to performing the final production migration.
When a cloud instance has both Jira and Confluence activated, you cannot take a full backup of Confluence and restore it to the cloud. So the team rolled up their sleeves and manually migrated (300) spaces flawlessly.
Due to our multiple cycles of migration testing, we were able to generate a detailed runbook that made the final production migration straightforward and smooth. We successfully completed the consolidation of all four Jira and Confluence cloud instances over a weekend and the teams began using the new cloud instances the following Monday.
By the time we reached Phase 2, Atlassian had rolled out the migration assistant tools for both Jira and Confluence, which made life easier for the team. We didn't have to monitor the migration process at the same level as we did during Phase 1. However, because the tools were still new, the team still performed four test runs to ensure the assistants worked as advertised. The assistants also provided critical pre-migration checks so our team of certified experts could be proactive resolving migration issues instead of waiting until after the test migrations, which took hours to execute, to discover what went wrong.
After fully vetting the assistants, we generated a new and improved runbook and we were able to reduce the client's migration costs by eliminating several manual aspects of the process and using the assistants automation capabilities. The biggest value points provided by the assistants is that the team did not have to manually migrate the Confluence spaces this time around and the pre-migration checks such as project and space key conflicts, duplicate users, and users with bad emails.
This phase was solely focused on migrating the client's test management data from Targetprocess (TP) to Jira. Our team worked with the client's test teams to trial several test management apps available for Jira in the marketplace. Ultimately, the team recommended TM4J--now known as Zephyr Scale and owned by SmartBear. However, the TP system did not offer an automated way to migrate its data so we had to rely on exporting to csv files. We also had to inform the client that they would lose their attachments, history, and comments, which they accepted because this loss was far less than the cost of renewing and owning the TP product.
The RenWare team implemented a Proof-of-Concept (POC) phase to ensure their recommended app would meet the client's requirements. We did not want to rollout this solution to production and discover any issues post-procurement of the app. Our team worked closely with the client's test teams to reconnect the dots in the Jira cloud test instance. Once approved, we were able to export the data out using the TM4J export function and maintain all work done in the test instance.
The client was thrilled with the new solution as it lived inside of Jira so the test cases could be directly linked to Jira issues making filters, dashboards and reporting easier and more accurate.
Our team of certified experts assessed the overall engagement during the qualifying phase and determined it was best to first centralize all instances and data and then cleanup and implement standards and best practices. This phase definitely required close communication with the client as we presented them with standards and best practices specific to their unique business requirements.
First we created reusable templates for Jira projects that covered issues types, workflows, custom fields, screens, notification, permissions, and project roles and quickly got approval across the board from management and stakeholders. Anyone that has tried to implement standards and best practices knows this is a feat in and of itself, but this simply means that our team fully understood how the business and teams work and presented them with an accurate solution.
There are three things to understand when presenting standardization to a client in regards to Jira. First the solution "must" account for the business needs, so ensuring easy cross-project reporting is a must. Second, one size "never" fits all. So the solution must balance a core set of standards while allowing teams to work as they see fit. Anything less creates an undesirable outcome on both sides and means neither side will use the solution. Finally, the solution must account for integrations. For example, if the client is using Aha! instead of Advanced Roadmaps, the solution must account for this and ensure a smooth, streamlined workflow. They should not have to manually update Aha! because the solution implemented doesn't provide the necessary automation to keep both tools in sync.
The client retained our team to rollout this new solution to all existing projects, which were in the hundreds. Cleaning up old, unused Jira projects, Confluence spaces, and associated content also ensured that their cloud instances performed optimally.
We practice what we preach at RenWare and utilize the Atlassian products for all of our engagements. We created a special Jira project and Confluence space and entered all work for each phase into the products. This allows the client to easily track our work and quickly see if there are any blockers that require their attention and track our progress for the duration of the engagement. This approach greatly reduces the need for meetings and eliminates the need for status reports. We create the necessary dashboards so upper management and stakeholders can feel confident that we are delivering on our promises.
As this client makes multiple acquisitions every year, our delivery team went above and beyond the call of duty and created a knowledge base around migrations and consolidations. This framework allows the client to determine if they can handle the migration themselves or if they should contact us for assistance. Doing this demonstrated that RenWare is not about the money, but about their success which they greatly appreciated.
"RenWare was a valuable partner and contributor to the successful completion of our Atlassian initiatives and business transformation. We were more than happy with their expertise and will continue to rely on it as we make additional acquisitions." - EVP & CTO