.webp)
Plan a Boring Atlassian Cloud Migration
Archived
By Avaratak
Avaratak’s independent Claude and Atlassian practices provide senior consulting. Our Atlassian consultants have at least five years of hands-on Atlassian experience; our Claude consultants bring extensive software development experience.
By Avaratak · Updated October 19, 2026
Avaratak is an Atlassian Solution Partner. Our Atlassian consultants bring 5+ years of hands-on experience in migration, governance, and administration.
How do you prepare for an Atlassian Cloud migration?
Prepare for an Atlassian Data Center to Cloud migration by assessing the source instance, reviewing app compatibility, resolving migration blockers, and rehearsing the move before production cutover. Use Portfolio Insights to assess readiness, the Jira or Confluence Cloud Migration Assistant for migration checks, and a test migration with user acceptance testing to validate the result.
A boring migration is a predictable migration: owners know what is moving, the team has tested the critical workflows, and the cutover plan reflects measured results. Early assessment gives you time to act on problems before the change window is under way.
Work backward from the Atlassian Data Center end-of-life milestones when choosing assessment and rehearsal dates.
This article began with the Atlassian Q1/Q2 2026 Cloud Transition Round-Up. The guidance below incorporates current product documentation, checked on October 19, 2026. Recommendations and the example are Avaratak guidance; product behavior is linked to Atlassian sources.
What does Portfolio Insights tell you before migration?
Portfolio Insights provides assessment information about your Data Center environment before you commit to a migration plan. Its cloud readiness assessment identifies migration blockers and recommendations across areas such as apps, users and groups, boards and filters, and data complexity. Use the findings to create an owned cleanup backlog. Passing an assessment is one input to readiness; the migrated system still needs testing.
Keep the assessment tools current
The Portfolio Insights data and metrics app downloads signed assessment queries from Atlassian. Current documentation says it is bundled with Jira Cloud Migration Assistant 1.12.50 or later and Confluence Cloud Migration Assistant 3.13.14 or later. Updating the relevant migration assistant installs it. Check these requirements again when planning your run.
Use instance health as well as cloud readiness
Performance Insights uses Apdex, a measure derived from response times, to show how key experiences are performing. Security Insights checks Data Center configuration against security practices and supplies recommendations for failed checks. These findings can be useful even when a migration is not imminent.
The schedules differ. Connected instances have automatic cloud-readiness reassessment every 28 days, which admins can disable. Security data is collected and uploaded every two hours; its dashboard shows the latest received results. Reassess after meaningful changes and use current findings when deciding whether to proceed.
How do you fix JCMA pre-migration errors?
JCMA remediation lets you resolve supported data-preparation errors for a migration without modifying the underlying Data Center source data. The guided interface is now documented; it is no longer simply a planned feature.
In the migration plan, open Pre-migration checks and the Data preparation section. Choose Fix remediable errors, supply the required information for the affected projects, apply the changes, and rerun the checks. For bulk work, the alternative is to download the remediation ZIP, edit its CSV, and upload the corrected ZIP. Follow the current remediation instructions for the exact error.
Remediation covers supported errors, and applying a file does not guarantee that every blocker is resolved. Review the new check results and record anything that still needs an owner. A successful pre-migration check does not establish that business workflows will behave as expected in Cloud.
What does a practical migration rehearsal look like?
Illustrative example: a service team has a Jira project with a Marketplace app dependency, attachments, permission restrictions, and a board used for reporting. This is a planning example, not a claim about a particular client engagement.
- Define the test scope. List the project, associated users and groups, relevant app data, and any linked Confluence content. Name the people who can accept the migrated result.
- Assess the dependencies. Review readiness findings and the app migration path. Decide how unsupported behavior will be handled before running the test.
- Resolve supported blockers. Run the assistant checks, provide approved remediations where needed, and rerun the checks. Keep an issue log for remaining findings.
- Run the test migration. Use the agreed test environment and record the duration and steps. Follow Atlassian guidance for migration testing.
- Validate real work. Have the owners check representative work items, attachments, access restrictions, boards, reports, and required app behavior. Record each failure, its owner, and the result of the retest.
- Update the runbook. Document the tested sequence, expected timings, communications, acceptance checks, and the decision to proceed or stop. Agree on recovery steps before the production window.
The useful output is a tested runbook and an evidence-backed readiness decision. Treat a representative project as a way to learn the mechanics. Full production scope can contain different dependencies and still needs appropriate validation.
For the access portion, our Atlassian permissions audit provides a review structure to use with the owners.
Do hosted and incremental migrations reduce downtime?
Hosted migration and incremental migration solve different problems. Hosted moves migration processing to Atlassian infrastructure. Incremental migration transfers changes to core product data after an initial full copy, which can reduce the data left to move during cutover.
Atlassian explicitly distinguishes them in its Hosted and Incremental Migration documentation: hosted migration alone does not improve downtime. Marketplace app data still migrates in full, even when core data uses incremental transfers. Plan the app work and validation into the change window.
Access is limited to qualifying customers. Confirm eligibility, product support, and the proposed migration path with Atlassian before putting this tooling on the critical path. Estimate downtime from the chosen method, data and app scope, and measured test results.
What else should you check before cutover?
Migration traceability. The Q1/Q2 roundup describes an optional JCMA setting to add migration timestamp details to entity descriptions. Decide whether that information is useful for your records and test its effect before enabling it for production.
Licensing and access. Confirm the intended user and agent populations, editions, and app requirements alongside technical planning. Our Atlassian licensing guide explains why this deserves a separate review.
The Jira Cloud migration cost guide separates delivery work, internal effort, subscriptions, and transition overlap for budgeting.
Tool access. Portfolio Insights is a free feature, but using it requires an Atlassian organization and the relevant administrative permissions. If a live connection is unsuitable, Atlassian supports manually uploaded assessment data. Confirm the connection and data-handling approach with your administrators.
Can the Cloud transition agent help?
The Cloud transition agent is documented as a beta for participating organizations. Organization admins using JCMA can use it to help interpret migration logs, error codes, and run history. It recommends next steps and requires confirmation before making changes.
Check availability in your organization. Keep a named person responsible for reviewing recommendations and validating outcomes. The broader principle is the one we discuss in closing the context gap between AI and your business: useful assistance depends on the right context. Migration logs still need to be interpreted against your operating requirements.
The Avaratak Take
Do the first assessment while there is still room to change the plan. Assign owners to findings. Review instance health. Rehearse remediation and test the workflows people depend on. Keep the readiness picture current as the source environment changes.
Our practical recommendation is to agree on the acceptance checks before choosing the production date. That gives the team a clear way to decide whether the migration is ready and a clear reason to pause when it is not.
The best migration story is one nobody needs to tell afterward because the move behaved as expected. Bring your assessment, app inventory, and test findings to a migration planning conversation with Avaratak.