This document lists all the information that needs to be collected, questions asked, and actions taken to complete a successful Atlassian Jira migration.
- List your Company's Team and responsibilities >
- List Client team and responsibilities >
- Is your Confluence set up for access by the client?
- Has a client Migration Estimates and Delivery Progress page been created?
- Have all tasks been estimated?
- Who will update the Migration Estimates and Delivery Progress page and how often will it be updated?
- List the applications on the receiving instance including versions.
- List the applications on the migrating instance including versions.
- Are the versions for each application aligned?
- Are there applications missing on the receiving instance? Must these be setup and migrated?
- What is the migration type:
- Server → Server
- Cloud → Server
- Cloud → Cloud
- Are the applications integrated with third-party applications? > List.
- Do the applications have custom code that may break on migration?
- Is there any other customization that may break on migration?
- Is an upgrade required to align versions?
- If an upgrade is completed, what can or will break?
- Third-party integrations
- Custom coding
- Other Customisation
- List addons on receiving instance.
- List addons on migrating instance.
- Which addons are missing on the receiving instance?
- Are there addons that cannot be upgraded (no updated version)
- List addons that must be migrated.
- List addons that will not be migrated.
- Are there addons that may not work on the receiving instance?
- List the licenses on the receiving instance including addons.
- List the licenses on the migrating instance including addons.
- List the licenses that can be used from the migrating instance.
- List any new licenses that are required on the receiving server.
- How do they manage users and groups on receiving instance?
- How do they manage users and groups on migrating instance?
- How will users be migrated to the receiving server?
- How will the migrating users login to the receiving server?
- How will groups be migrated to the receiving server?
What to Migrate?
- Do all projects / spaces need to be migrated?
- Send a list of project / spaces to the client for review and approval.
- List the projects / spaces that can be archived / deleted.
- How are the projects / spaces archived?
- Who will archive or delete the projects / spaces?
- Are there independent projects that need to be converted?
- How are the migrating instances permissions retained on the receiving instance?
- Do the permissions on the receiving instance need to be modified to accommodate the migrating instance permissions.
- Can project roles be migrated successfully or are there conflicts?
- What environments are needed to complete the migration including testing? ( Staging | Test | Production)
- Who will set up these environments and manage them?
- Is any software / addons needed to complete the migrations, for example, Project Configurator?
- How will data be backed up on migrating server?
- How will the data be migrated from migrating instance to the test instance?
- How will the data be migrated from the migrating instance to the production instance?
- Who will complete the data migration
- How will conflicts be identified for each application and addon? Project configurator
- Have conflicts been identified for and how to solve them
- Project Names
- Project Keys
- Issue Types
- Issue Type Schemes
- Issue Type Screen Schemes
- Screen Scheme
- Project Roles
- Security Groups
- Workflow Statuses
- Workflow Schemes
- Custom Fields
- Field Configurations
- Field Configuration Scheme
- Permission Schemes
- Notification Schemes
- Will triggers, conditions, validators, and post functions still work after migration?
- Are there custom triggers, conditions, validators, and post functions?
- List links that must be updated in Jira and or Confluence.
- Who will make these updates
Migration Steps Checklist
- Following the test migration has a Migration Step Checklist been created for the production migration?
- Who will test the test migration at our side?
- Who will test the test migration at Client?
- How will the test migration be tested?
- What tests need to be performed?
- Who will test the production migration at One Dot?
- Who will test the production migration at Client?
- How will the production migration be tested?
- What tests need to be performed?
- Will the migrating applications need to be taken off line?
- If the migrating applications need to be taken off line:
- Who will do it?
- When will it be done?
- Will the client be required during the migration down time? If so, who will that be?
- How long will the applications be offline?
- If a roll back is required, how will that be completed?
- Is a rollback process identified, documented, and ready to be implemented?