Atlassian Cloud Migration: a practical guide for Jira & Confluence

Migrating Jira, Confluence, and Bitbucket from Server or Data Center to Atlassian Cloud is one of the most common projects we get called in on at Arventra — usually after a team has tried once internally and hit a wall. With Atlassian's Server end-of-life behind us and Data Center pricing climbing every year, the question for most organizations isn't whether to move, it's how.

This post is the playbook we actually use, distilled from migrations spanning healthcare networks, fintech, and global brand-protection firms. It covers discovery, app audit, test migration, cutover, rollback, and the specific traps that derail teams trying this without prior experience.

The four phases at a glance

Phase 1 — Discovery and app audit

Before touching the Atlassian Cloud Migration Assistant, map the current estate end-to-end. This is the single highest-leverage week of the project — every hour spent here saves a day on cutover weekend.

Installed apps and their Cloud equivalents

Roughly 30% of marketplace apps don't have a Cloud version, or have one with reduced features, different data models, or a different vendor. This is the biggest source of nasty cutover-day surprises. For every installed app, document:

• Does the same app exist on Cloud? If not, what's the closest replacement?
• Does the Cloud version migrate data automatically, manually, or not at all?
• Are there licensing changes (per-user → flat fee, etc.)?
• Is the app actively maintained on Cloud, or in deprecation?

Customizations

Custom workflows, custom fields, custom schemes, ScriptRunner scripts, database-level integrations. Each one needs an explicit plan: migrate as-is, rebuild in Cloud-native automation, or retire. ScriptRunner Cloud has a smaller API surface than Server — many scripts need a rewrite.

User and group inventory

Export the full user list with email addresses, group memberships, and IdP attributes. Plan SSO and SCIM mapping before the cutover, not after. Atlassian Cloud uses email-based accounts via id.atlassian.com — a single character mismatch creates a duplicate user with no history.

Integrations

CI/CD webhooks, Slack/Teams bots, Zapier flows, monitoring tools, custom scripts, mobile app deep links. All of these reference the source instance URL and (often) source credentials. Make an integration register with owner, criticality, and re-point plan for each.

Phase 2 — A clean test migration

Always run at least one full test migration into a sandbox Cloud site before the production cutover. We use it to:

1. Time each phase end-to-end (most teams underestimate by 2–3x).
2. Verify users map correctly to Atlassian accounts via email.
3. Validate that custom fields, workflows, and permission schemes survived the transfer.
4. Spot-check attachments, comments, and history on 50–100 representative issues across multiple projects.
5. Test every critical integration end-to-end against the sandbox URL.
6. Generate a punch list of fixes for the real cutover.

Atlassian Migration Assistant produces a JSON report of every project, user, and app processed. Treat it as required reading — every warning is a real issue you'll see at scale.

Phase 3 — Cutover runbook

Cutover is a sequence, not a single switch. Our standard runbook, timed to a Saturday morning so users return Monday on Cloud:

1. Friday 17:00 — Freeze writes on the source instance (banner + admin-only write permission).
2. Friday 18:00 — Final source backup for compliance and rollback.
3. Friday 18:30 — Run the delta migration via Atlassian Migration Assistant. Only the data changed since the last test migration moves; this is much faster than a full migration.
4. Saturday 09:00 — Verification window. A pre-defined smoke-test team validates 20 critical workflows, 10 dashboards, and every integration.
5. Saturday 12:00 — Re-point integrations (Slack, GitHub, monitoring, Zapier) to the Cloud URL. Each integration owner confirms in a shared channel.
6. Saturday 14:00 — Update SSO/SCIM in your IdP to point at id.atlassian.com.
7. Saturday 16:00 — Pilot group access. A 20-person cross-functional group uses Cloud for two hours; any P1 issue triggers rollback discussion.
8. Sunday — Soak time. Source stays read-only, Cloud is live but with limited access.
9. Monday 06:00 — Announce and open to all users with new URLs, FAQ, and a dedicated support channel for week one.

Rollback plan

Keep the source instance running and read-accessible for at least two weeks post-cutover. If a critical issue surfaces, you have three options:

• Full rollback — re-open source for writes and revert routing. Only viable in the first 24 hours; after that, the data diverges and you lose work.
• Partial rollback — export specific projects from Cloud, re-import to source. Useful when one team has a blocking issue but the rest of the org is fine.
• Fix forward — almost always faster once users are productive on Cloud. Most "rollback" conversations end here.

Common mistakes we see (and how to avoid them)

• Skipping the app audit. Discovering on cutover day that a key marketplace app has no Cloud equivalent. Fix: full audit in week one, with a "no Cloud version" decision logged for every gap.
• Treating users as a copy-paste. Email mismatches create duplicate Atlassian accounts and orphaned issue history. Fix: normalize email addresses in the source before migrating; use SCIM where possible.
• Forgetting integrations until cutover. CI pipelines that posted to Jira go silent on Monday morning. Fix: integration register with owners, tested in the sandbox migration.
• No comms plan. Users discover the move from a broken bookmark, not an announcement. Fix: T-2 weeks announcement, T-1 week reminder, cutover-day update, week-one daily digest.
• Migrating dead projects. 40% of projects in a 5-year-old instance are abandoned. Archive them on source before migrating to reduce time, cost, and clutter.
• Underestimating timezone coordination. Global teams need cutover windows that don't trap APAC users with a broken instance for 12 hours.

Frequently asked questions

How long does an Atlassian Cloud migration take?

End-to-end, 6–12 weeks for a typical mid-size instance (500–2,000 users, 50–200 projects). Larger or heavily customized estates run 3–6 months. The actual cutover weekend is one weekend — everything else is preparation.

Is there downtime?

Yes — the source instance is read-only from Friday evening through Monday morning during cutover. Read access is preserved so users can reference issues if needed. There's no zero-downtime path for the official Atlassian migration tooling.

What about apps that don't have a Cloud version?

Three options: find a Cloud-native replacement, rebuild the functionality in native Jira automation, or accept the gap. We've successfully replaced 80% of "no Cloud version" apps with native Cloud features that didn't exist when the app was originally installed.

Can we migrate Jira but keep Confluence on-prem?

Yes, but it's not recommended long-term — you lose the integration features (smart links, page-issue embedding) that make the suite valuable. Most teams that try a split migration consolidate within 12 months.

What does Cloud cost vs Data Center?

For most teams under 1,000 users, Cloud Premium is cheaper than Data Center once you factor in hosting, ops, and DR. Above 5,000 users it gets closer and Enterprise pricing applies. We always run an explicit TCO comparison in the discovery phase.

Do we need a partner, or can we do this ourselves?

Small instances (under 100 users, few apps, no customization) can DIY successfully. Anything larger benefits from a partner who has seen the failure modes — the cost of one botched cutover usually exceeds the partner fee.

Get the migration done right

Cloud migration is mechanically simple but operationally unforgiving. If you'd like an experienced team to run it for you, our Atlassian consulting practice has shipped these end-to-end across multiple industries. We handle discovery, sandbox migration, cutover, and the first 30 days of post-cutover stabilization.