The Jira migration starts before the data moves

Agree what the move should enable and what belongs in scope. List the sites, projects, users and supporting tools. Identify overlaps with wider improvement, such as simplifying workflows or consolidating instances. Each change needs a clear purpose and someone authorised to decide it.

Use a decision log from the start. Record the choice, owner, evidence needed and date for resolution. Include the consequence of a late decision. Distinguish a task waiting for delivery from one waiting for agreement, then bring the right people into the discussion.

Inventory the Marketplace apps people actually depend on. For each app, check Cloud availability, the features your teams use and the vendor's supported data migration route. These are separate questions: a Cloud edition may have different capabilities or require additional migration steps. Record whether to migrate, replace, redesign or retire the app.

Treat integrations as their own workstream. Identify the systems connected to Jira, their owners and the processes they support. Agree how authentication, endpoints and access will be checked in Cloud. Give each important connection an acceptance test. An app count or a list of installed tools cannot show whether the business process still works.

Atlassian's migration assessments can identify invalid or duplicated user email addresses that block a migration. Run the assessment early enough to resolve issues, then repeat it close to the migration to catch changes. Keep responsibility for remediation clear, especially where decisions depend on an identity or security team.

Review the destination access model with its owners. Consider groups, permissions, administrators and people who need testing access. Agree how users will learn about changes and ask for help. A successful data move still needs people who can reach the right information and understand how to work with it.

A test migration gives the team a chance to inspect the destination, find issues and understand the steps required for production. Define representative checks before the rehearsal. Include important content, permissions, app data and integrations, then involve people who use the workflows in practice. Record exceptions and who will resolve them.

Use what you learn to improve the runbook and communications plan. Capture timings, prerequisites and manual steps rather than relying on an optimistic estimate. Repeat the checks affected by a change. Rehearsal should leave the readiness review with evidence of what works and a clear account of the risks still open.

Before production, bring together the scope, test results, unresolved risks and required approvals. Make the decision maker explicit. Agree the change window, user communications, response responsibilities and recovery options appropriate to the chosen migration method. A single green status should not hide an unresolved issue that needs acceptance.

Plan what happens after the move. Name the owners of early support, defect triage, integration checks and user guidance. Separate urgent operational problems from improvements that can enter a planned backlog. The handover should explain what has changed, where the evidence sits and who can make the next decision.