What is Hosted Cloud Migration Assistant?

What is Hosted Cloud Migration Assistant?

The Hosted Cloud Migration Assistant is Atlassian’s new tool for migrating Data Center instances to Atlassian cloud.

It allows you to copy data from your Data Center instance to a migration environment hosted on Atlassian cloud and run the migration to your cloud site from the new location. Additionally, it enables on-demand transfer of changes in your Data Center data from the migration environment to your cloud site.

The Cloud-hosted migration assistant is currently available only to large customers who qualify a set of criteria.

How is the Cloud-hosted migration assistant different?

Here’s how the Cloud-hosted migration assistant differs from the Jira Cloud Migration Assistant:

  • No dependency on your infrastructure. Heavy migration processing runs on Atlassian-hosted infrastructure rather than your finite on-prem hardware. This removes the scale ceiling and resource contention that constrained JCMA/CCMA, and it means migrations no longer compete with your live DC for resources.
  • No manual staging setup, no repeated DB dumps. Atlassian provisions the hosted environment for you; you don't set up or maintain a separate staging instance or ship database dumps for every attempt.

  • Lightweight on your DC. A Migration Connector plugin installed on your DC streams data to the cloud with minimal impact on your production environment.

  • Run migrations on your schedule. Because the environment lives in Atlassian's cloud, you can run test or production migrations whenever and however you want — not just when your infrastructure is free.

  • Same Marketplace app support as JCMA. Hosted supports migration for the same apps as Jira Cloud Migration Assistant.

  • Easier debugging and higher reliability. Migration errors can be diagnosed and fixed in the cloud environment, with better access to logs — reducing risk and turnaround time.

How a Hosted migration works

  1. Install the Migration Connector plugin from the Atlassian Marketplace on your DC instance.

  2. Replicate your data. The connector streams your Atlassian database, attachments, and supported Marketplace app data to Atlassian's hosted storage.

  3. Provision the cloud staging environment directly from Admin Hub once your data is replicated.

  4. Run your migrations. Use the hosted environment to perform your own test and production migrations to your target Cloud site — as many test runs as you need, without touching your live DC.

  5. Validate and run the final production migration. After testing, initiate the final production migration when you're ready.

What is Incremental Migration?

Incremental Migration builds on Hosted to enable low-downtime migrations. After an initial full copy of your data, Incremental transfers only the changes (deltas) on demand from the Atlassian staging environment to your Cloud site. Because the bulk of your data, attachments, and history is already migrated ahead of time, only the most recent changes need to move during the final cutover — so the downtime required for your core product data is minimal.

Caveat: apps are not incremental. Incremental sync covers core product data. App data is not migrated incrementally — it is migrated in a full pass. Plan to freeze app changes and migrate apps as part of the cutover window.

Why it matters

  • Low-downtime cutover. You migrate a snapshot, then keep migrating incrementals over time. By your planned migration date the remaining volume is small, so overall downtime is significantly reduced — the majority of data, attachments, and history is already in Cloud.

  • More time for the hard parts. Because the core data migration now takes just a few hours, the rest of your cutover window (e.g., the weekend) can be spent migrating the more complex app data and resolving any errors or edge cases that surface.

  • Prepare your Cloud site in advance. You can spin up a sandbox and keep it in sync with snapshot + incremental data, so your Cloud site is almost ready before the final migration. After the last incremental run, that same sandbox can be flipped to production and used directly.

  • No need for multiple, repeated test migrations. Start with test migrations, fix issues in pre-flight, and use remediation and reconciliation to find transformations, fix data, and build confidence in Cloud. After one or two incremental runs you can flip to production — collapsing weeks of repeated dry runs into a single, incrementally-synced path.

  • Fixes persist to production. Because the same Cloud site is used through testing and go-live, configuration and data fixes made during UAT carry straight into production. No re-doing work on a fresh site — so most post-migration fixes are already in place on day one, and Cloud adoption is faster.

  • DC stays live during rehearsals. Your users keep working in DC while the staging environment stays continuously up to date, letting you validate migrations without impacting production.

How an Incremental migration works

  1. Initial full migration. Atlassian uses Hosted to replicate your DC data and perform a full migration to your Cloud test/sandbox site.

  2. Keep working. Your users continue in DC while the staging environment is kept up to date with ongoing changes.

  3. Incremental (delta) runs. Run "Get updates" to transfer only the changes made since the previous run. Repeat as needed, validating and remediating along the way.

  4. Final cutover. Apply the last incremental, migrate app data, and flip the site to production — switching your users to Cloud with minimal downtime.


Hosted and Incremental Comparison

Hosted Incremental migrations work together to enable an infrastructure independent, incremental migration.


Aspect

Hosted Cloud Migration

Incremental Cloud Migration

Core value

Independence from your own infrastructure

Incremental migration that allows lower-downtime + cloud readiness

How you migrate

Same as classic — run test migrations to Cloud sites, then one final production run (typically over a weekend)

Full copy once, then delta-only "Get updates"; flip the synced sandbox to production

Downtime

Similar to classic (no downtime improvement by itself)

Significantly reduced final cutover downtime

Repeated test runs

Supports multiple isolated test runs before a single cutover

Fewer runs needed; validate on the site you promote to prod

App data

Same app support as JCMA (full migration)

Core data incremental; app data migrated in full (not incremental)

Value proposition at a glance 

What Hosted solves

What Incremental adds

Migration logic moves to Atlassian cloud — no manual staging infrastructure, no repeated DB dumps, no dependency on customer infrastructure.

Delta-only sync after the initial full copy → low-downtime final cutover and a Cloud site that's ready in advance.


Key benefits:

  • No dependency on the customer's infrastructure — migrations run on Atlassian-hosted infra.

  • Unlimited test runs; DC stays live during rehearsals.

  • Same Marketplace app support as JCMA.

  • Significantly reduced cutover downtime (Incremental).

  • No need for multiple test migrations — migrate to a sandbox and flip it to production.

  • Faster post-migration start, because UAT fixes persist into the production site.

How can you use the Cloud-hosted migration assistant to migrate data?

Here's how you can migrate data using the Cloud-hosted migration assistant: Runbook for Hosted and Incremental Migrations

Further reading

Hosted Cloud Migration Assistant - System and Data Flow

Runbook for Hosted and Incremental Migrations

Set up database for Cloud-hosted migration assistant

FAQs about Cloud-hosted migration assistant

Product and Version Support for Hosted Cloud Migration Assistant


Last modified on Aug 21, 2026

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.