Deciding to migrate to Cloud is one thing; succeeding at the migration is another. Once the decision is made, the risk no longer comes from strategy but from execution — data that won't transfer, apps with no equivalent, users losing their access.
You only migrate well what you know. The first step is an exhaustive inventory: number of users and groups, projects and spaces, workflows and custom fields, installed apps, external integrations (CI/CD, SSO, third-party tools). This inventory often reveals surprises: dormant projects, apps nobody uses anymore, forgotten integrations.
It's also the right time to clean house. Migrating ten years of useless configuration means paying to ship boxes you'll never open. Archiving and cleaning up beforehand lightens the migration and improves the new instance's performance.
This is where most migrations go off the rails. A Data Center app doesn't necessarily have a Cloud equivalent, and when it does, the data doesn't always migrate automatically.
App assessment must happen at the very start, not the night before the migration. A single critical app with no migration path can justify rethinking the whole timeline.
On Data Center, users often come from an LDAP/Active Directory. On Cloud, identity goes through Atlassian Account and, ideally, through an identity provider (SSO/SAML) with automatic provisioning.
The sensitive points: account matching (a single user must not be duplicated), preserving group memberships (on which all permissions depend), and handling inactive accounts you don't want to migrate or pay for. A botched identity migration is paid for in support tickets on launch day.
You never migrate straight to production. Atlassian's tools (Jira Cloud Migration Assistant, Confluence Cloud Migration Assistant) let you run a migration to a test Cloud site.
This test migration measures the real duration (decisive for planning the cutover window), validates that data arrives intact, surfaces configuration gaps, and trains the team. You repeat it until the result is clean and the process predictable.
The production migration is done by freezing the old instance (read-only) during the transfer, so data created mid-migration isn't lost. The length of this freeze — a few hours to a weekend depending on volume — must be communicated widely and scheduled outside activity peaks.
A rollback plan must exist: if something goes wrong, you know how to return to the Data Center instance without loss. You only decommission the old instance after full validation, never the same day.
The work doesn't stop once data has transferred. You must validate methodically: users can log in (SSO), permissions are correct, apps work, integrations (CI/CD, notifications) are reconnected, automations run, reports show the right data.
The first days are critical: plan reinforced support, a dedicated channel to report anomalies, and someone accountable for each category of problem. That safety net is what turns a technically successful migration into one the teams experience as successful.
Migration technology is mature; Atlassian's tools work. The difference is in preparation: the inventory, the honest app assessment, the repeated test migrations and a cutover plan with no blind spots.
At Nimbax we support each migration end to end — from inventory to post-cutover validation — with a documented plan, realistic windows and a rollback always possible. A migration should never be a leap into the void.
