Jira Migration from Server to Cloud

The client's problem

In the case of Planeta, several factors had to be taken into account:

• End of Life of the Product. Atlassian will stop supporting Jira Server in February 2024.
• Excess of custom configurations and consequently increasingly complex administration.
• Tendency to loss of functional knowledge due to the complexity of the solution.
• Possible impact on other areas when implementing new functionalities. Probability of increasing issues and consequently difficult change management. 
• Intention to reduce costs:
  • License costs: Both users licenses and instance and plugin maintenance. 
  • Infrastructure costs: Maintenance (IaaS)

The client's objectives

Planeta's IT Department had several objectives: 

• Change to a different configuration in order to have the ability to scale to multiple project resolvers from the same Customer Portal.
• All tickets had to be migrated in order to maintain a history, whether they were open or closed.  
• Implement a CMDB to maintain centralized management of all changes related to their services and applications. Integrating it into the tickets and their processes for better control and tracking. 
• To speed up the work of the first level agents in the Service Management portals, it was also necessary to automate tasks and notifications on all linked tickets.

Main challenge

To understand the main challenge, the starting point was a configuration based on the replication of actions between Service Management and Software projects. The change to the new model meant transforming the entire workflow defined in the projects, restructuring the permissions system and the user groups involved. 

Thus, not only more than 140,000 tickets had to be migrated, but also unresolved tickets had to be transformed to the new Cloud system in order to be able to continue processing them. 

In addition, the structure of the CMDB (Configuration Management Database for asset control) was in another medium, so it had to be incorporated into the new system and integrated with the fields that already used their tickets. 

As for the users, those who were already registered in the Cloud environment had to collect all the data they had in the Server environments. They had different domains and repeated emails, which made the migration difficult because in the Cloud the emails must be unique and only the domains claimed by the company can be managed by the administrators.

Solution

In order to meet the client's needs in terms of administration and scaling of functionalities, rules were implemented using a functionality offered by Jira by default called "Automations". This allows configuring transparent automated actions for users, which are activated according to the configuration determined by the administrators. 

During the migration, rules were created that detected when a migrated ticket was still unresolved and then replicated it with the new settings linking to the original to maintain the history. 

In addition, to minimize escalation time, the creation and management process was automated. During creation, all fields with important values are replicated and the user is only asked to specify the minimum necessary information, so the new ticket is created with the previously configured values. 

Other actions carried out

Additionally, during the management of the escalated ticket, automatic actions were created that modify the related request so that the user only has to worry when the ticket is in certain states. 

Regarding the use of generic workflows and management of multiple projects, they have been refactored taking into account and updating to the new requirements. 

The result of this refactoring is reflected in watertight projects with their specific configuration for each area. Also taken into account in this phase was the rethinking of groups, roles and permissions, standardizing the model and thus being able to scale in a uniform way in the future.   

Regarding users, in order to provision them to the application and manage their credentials, a new connection to the client's Active Directory was implemented with the Atlassian Access tool. To do this we had to define a unique domain for the company and thus we could claim all users registered in Atlassian Cloud who had the corporate mail. 

Finally, through the project planning established at the beginning and the periodic follow-up meetings marked, the new instance was put into production on the desired date.