Addteq Services recently had the opportunity to assist a manufacturer of industrial laminates with their Server to Cloud migration of Jira and Confluence.
The Situation
The core objectives of this project were to:
- Migrate Jira and Confluence from Server to Cloud
- Implement an alternative to WorklogPro, which has no Cloud version
The customer attempted to migrate to the cloud in the past, and all attempts failed, which is why Addteq was chosen as their cloud migration partner.
Challenges Faced
Before contacting Addteq Services, the customer had attempted to migrate to the Atlassian cloud independently and could not complete the migration. Addteq was brought in to investigate the failures and find a plan for safely moving all of the data. After performing a complete assessment of the projects, spaces, add-ons, and users, Addteq reviewed the current failures and performed several test migrations, and identified many challenges.
Server and Cloud-side Issues
- On the Server side, many inactive objects existed in the customer’s Jira instance, resulting in clutter. Many Jira workflows contained broken conditions, validators, and post-functions left over from plugins that were no longer in use. While not a showstopper, we felt it was best to clean up and consolidate as much as possible to ensure clutter was not carried over to the cloud, allowing the customer to start fresh in their new environment.
- In most cases, organizations looking to migrate to the Atlassian cloud have little to no experience with the cloud tools and are starting fresh. However, that was not the case here. The destination site in the Atlassian Cloud had long ago been purchased and was actively being used. This site also contained many duplicates and unused artifacts from previous unsuccessful migration attempts, which needed to be cleaned up before new migrations could occur.
- The customer relied heavily on dashboards, filters, and boards. At the time of migration, the JCMA did not natively migrate global permissions, dashboards, cross-project boards, boards not connected to the projects being migrated, boards that belong to inactive users, or filters on boards that are not migrated. A bug in JCMA versions greater than 1.6.5 (which has since been addressed) prevented dark features that can be used to migrate filters, boards, and dashboards in a JCMA plan.
Time Tracking Requirements
- The customer relied on WorklogPro as it offered the ability to create reports that grouped work logs based on values in a specified custom field, representing internal divisions in this case. The ability to group work logs by division in reports was critical to their business and needed to be replicated in the cloud. However, WorklogPRO was not available in the Atlassian Cloud.
- The customer selected Tempo Timesheets as an alternative to WorklogPro, given that it is widely recognized as the best-in-breed choice for timesheets in Jira. While available in the cloud, Tempo Timesheets cannot use custom fields for the same purposes, nor will it include them in their standard downloadable time log reports.
- When installed, Tempo Timesheets initiates a data synchronization operation. Based on observations in this migration, this sync does not include historical work logs. There were also a series of installation issues that required the assistance of Tempo Support both in screen shares and offline, with the support team performing back-end operations and implementing fixes.
- While testing, we encountered a known Tempo bug that resulted in an “Issue not found” error when trying to log time.
User Migration Issues
- The customer maintained two LDAP directories. Several hundred users were listed between both directories, only a fraction of which were to be migrated. Also present were several hundred groups, again, only a fraction of which were needed in the cloud.
- The JCMA identified many issues with duplicate user accounts, multiple users sharing the same email address, invalid email addresses, and users with no email address.
- The customer had 49 active users and a 50-user cloud license. However, certain server-side activities reactivated some inactive users without notice or warning, resulting in failed attempts to migrate to the production cloud site. These failures were caused by exceeding the user tier on the cloud site.
The Solution
After addressing all of the challenges and taking the actions outlined below, Addteq migrated all Jira and Confluence data successfully to a test site using the Cloud Migration Assistants. Addteq thoroughly tested Jira and Confluence before handing them over to the customer for user acceptance testing. Once UAT was complete, we scheduled a full production migration and migrated all Jira and Confluence data to the production site.
Cleanup
- Before the migration, Addteq deleted all inactive and unused workflows, screens, and other unnecessary objects from the Server site after receiving permission from the customer.
- Addteq deleted all leftover migration artifacts from prior migration attempts from the production cloud site before the final migration.
- After cleaning up the production cloud site, a site backup was taken and restored to a test site so that Addteq could perform a new test migration in an environment identical to the final production site.
Users
Addteq and the customer worked together to resolve all issues associated with user accounts:
- All accounts with invalid email addresses were updated with valid email addresses.
- User accounts without email addresses were updated with new, unique, and valid email addresses.
- User accounts that shared email addresses were updated with unique email addresses.
- Duplicate user accounts were deleted from the internal directory.
- Addteq only migrated users and groups explicitly needed for the projects and spaces being migrated, preventing an excess number of users from appearing in the customer’s cloud site while also allowing us to work around user account errors that could not be resolved via the methods above.
Filters, Boards, and Dashboards
After migrating Jira to the cloud with the latest version of the JCMA, Addteq downgraded the JCMA to version 1.6.5, allowing us to enable and use a set of dark features to migrate filters, boards, and dashboards to the cloud site. Once the migration was complete, the dark features were disabled, and the JCMA was upgraded to the latest version.
Replacing WorklogPro
Once installed, Tempo Timesheets was configured according to the documentation. Addteq addressed the “Issue not found” error by following the workaround steps provided by Tempo.
Tempo Support fixed an issue on the back end, which prevented historical work log information from appearing in Time Logged reports.
Addteq created a process for the customer that used Tempo’s bulk edit feature to migrate their WorkLog Pro category values to Tempo Accounts.
Confluence
Confluence was migrated to the Atlassian Cloud using the CCMA without error, incident, or special handling.
The Outcome
Immediately after migrating Jira and Confluence to the Atlassian Cloud, the customer onboarded their user base and began using the tools as soon as they were available. The customer is delighted with the outcome, as they had no success in their attempts to migrate to the Cloud and did not have the time or capacity to work through all the migration challenges. We look forward to working with this customer again soon!
Are you ready to take your organization to the next level in the Atlassian Cloud?
