SEE ALSO:
- Jira Integration
- Native Issue Level Integrations
- Native Jira integration: End User Guide
- Native Jira Integration: Technical Overview
- Native Jira Integration: Setup Guide
- Migration of synced data to a new profile and profile splits (BETA)
- Jira Integration Limitations
- Apptio Open Token for additional security of Jira Data Center Webhooks
Jira can migrate from Server to Cloud in several different ways:
- XML backup of Jira and restoring it in Cloud - Preferred option as integration migration will be the easiest in this case.
- JCMA - Jira Cloud Migration Assistant. For more information, see https://support.atlassian.com/migration/docs/what-gets-migrated-with-the-jira-cloud-migration-assistant/
Integration sync relies on Jira IDs, and not just the Jira Keys of synced issues, but numeric IDs of items that do not have Jira Keys like attachments, comments, and Jira sprints. The items that do not have Jira Keys depend on their parent issue sync rule.
In the case of migration using (1) XML backup and all IDs remain the same, then migration could be fully supported, and sync will restore and be fully functional in an hour. This is the easiest option for integration - Dev Team only does the profile conversion from Server to Cloud type, and everything is in sync since there are no changes in Jira data.
In the case of (2) migration with JCMA, all comments, attachments, and sprints get the new numeric ID in Jira Cloud. They will not be recognized with the old integration rules after migration to the new profile, as they are totally different entities.
We do not yet migrate synced comments, attachments, and sprints automatically while using the JCMA way of migration. Comments and attachments will sync as new, and this will cause duplicates on next issue sync. Sprints will have to be relinked manually.
Scenario for Option 1: XML backup/restore
- Customer migrates to Cloud and disables the integration profile.
- When Jira is moved to Cloud, TP Dev team does an integration backup, converts the profile type from Server to Cloud and resets the cache. Estimation: 0.5 hours.
- As soon as the profile type is changed, Jira user credentials and the URL are ready to be updated to the cloud ones and the new cloud profile can be enabled to resume sync with Jira Cloud.
Scenario for Option 2 – Jira Cloud Migration Assistant (JCMA)
Synced Comments, Attachments and Sprints will not migrate, they will reimport to on next resin of the parent item.
It's support requires some code changes planned for the beginning of January 2023. It’s suggested customers plan such migrations not earlier than February 2023 (and excluding comments, attachments, sprints sync migration).
- Customer creates a new Cloud profile.
- TP team must get access to both profiles (knows the ID and can request for mappings).
- Customer provides Jira scopes for (first) migration pack (Jira projects, issue keys that must be migrated to new profile).
- Targetprocess Dev team runs migration scripts for issues (Jira Keys) and switches them from the old server profile to the new cloud. As soon as this migration is completed, the scope could be removed from the server profile to stop syncing from server.
- Comments, Attachments and Sprints are not supported in this migration type yet (Sprints and Attachments is a subject for planning Q2-2023/PI 11).
More detailed instructions for this option will come up in mid-January 2023, when the Dev team tests it.
Still have a question?
We're here to help! Just contact our friendly support team.
Find out more about our APIs, Automation Rules, Mashups and custom extensions.