Data analytics provider merges multiple Jira instances into a single Enterprise instance

Addteq recently had the opportunity to assist a customer with migrating Jira projects and Confluence spaces from several business unit instances into their single Enterprise instance. The customer is a leading data analytics provider serving customers in insurance, energy and specialized markets, and financial services. This post details the work performed to migrate Jira projects to their Enterprise instance.

The team needed to merge multiple instances with many projects and spaces which potentially contained similar project and space keys. For example, the teams in APAC and EMEA can both have the project QA. All Jira project and Confluence space names were standardized to ensure unique naming and organized content according to the originating business unit, which was accomplished by prefixing each project and space key with the name of the originating business unit. For example, a Jira project named QA from the APAC business unit would need to be renamed to APACQA.

Original Merge Plan

For most business units, we received full system backups with attachments. Once received:

  • We unpacked the archived backup and executed custom scripts to rename all project keys and attachments and updated all Confluence links to point to the Enterprise instance. 
  • For some business units, we executed custom scripts to standardize user names to ensure they were in alignment with the Enterprise instance.
  • Once the XML and attachments were modified, we repackaged the backup archive and performed a full restore of the data on a temporary instance. 
  • Using Project Configurator, we exported projects from the temp server and imported the project into a development server configured identically to the Enterprise instance. 
  • The customer performed UAT on the imported projects in the development instance.
  • Once UAT was complete, we performed the same steps again, using Project Configurator to export projects from the development instance and import projects into the Enterprise instance.

Since the business units we actively using their projects, we would only work on one or two projects at a time until all projects from that business unit were merged into the Enterprise instance; that meant having to perform all of the steps above with every batch we received.

Revised Migration Plan

Although the original plan was successful for most business units, the execution took far longer than initially anticipated for one business unit with a particularly large Jira instance. Under the original process, updating the project names took over an entire day! Even if we assumed nothing could go wrong in the process at any time and no scripts would require re-running, we needed to work with a strict deadline, and this process was far too time-consuming for the schedule that had been worked out.

To solve this problem, Addteq revised the plan. Our new plan eliminated the development instance, importing directly into the development server. The revised plan was followed on a project-by-project basis:

  1. Project Configurator was used to export each project from the business unit’s instance.
  2. Once a project archive was received, we unpacked the archive and executed custom scripts to rename project keys and attachments and update all Confluence links to point to the Enterprise instance.  
  3. We then tested for additional errors and manually cleaned up the project import files to ensure all project keys were appropriately renamed and any other potential for error was addressed.
  4. Lastly, we imported the project into the same development instance used in the original plan using Project Configurator.

  5. The customer performed UAT on the imported project in the development instance.
  6. Once UAT was complete, we used Project Configurator to export the project from the development instance and imported it into the Enterprise instance.

The Result

Projects from each business unit were successfully migrated to the Enterprise instance of Jira using a combination of the two plans above. The ability to pivot and revise the migration plan as needed allowed Addteq to deliver results on time, without delay or data loss. The customer’s team was pleased with the final result and the level of inclusion and collaboration throughout the project.  

Do you need help with data merges or consolidations? Addteq is here to help.

Image by pch.vector on Freepik

M-Enabling Summit 2022 – Key takeaways

I attended the 2022 M-Enabling Summit in Washington DC on 24th October. M-Enabling Summit brings together key decision-makers from all sectors facilitating unique exchanges, collaborations,

Leave a Reply

Your email address will not be published. Required fields are marked *