Atlassian Cloud Migration: A Practical Planning Guide

Most Cloud migrations get described as a data move. They are not. The data move is the part tooling has largely solved. What consumes the calendar is everything around it: deciding what deserves to come, fixing what will not survive the trip, and convincing people the new thing works.

Decide what you are actually migrating

The first useful question is not how to move the instance but how much of it deserves to move. Instances running five years or more accumulate projects nobody owns, workflows nobody can explain, and custom fields created for a reporting request in 2019. A migration is the one moment when deleting things is politically easy. Use it.

Run an inventory before anything else: active projects and their owners, workflow schemes actually in use, custom fields and their fill rates, Marketplace apps and who depends on them, and every integration pointing at your instance. Anything with no owner and no activity in twelve months is a candidate for archive rather than migration.

Marketplace apps are the biggest variable

App remediation is where migrations slip. Every app lands in one of four buckets: it has a Cloud version at parity, it has a Cloud version with feature gaps, it has no Cloud version but native functionality now covers it, or it has no path at all and something must be rebuilt.

Two things make this expensive. App data does not always migrate even when the app exists in Cloud — some vendors provide migration paths, others expect reconfiguration by hand. And apps are licensed at the same user tier as their host product, so a migration is a good moment to ask which apps still earn their price.

The four phases

• Assess — inventory, app remediation plan, target architecture, and a decision on what gets left behind. Typically two to four weeks.
• Remediate — rationalize workflows and fields, resolve app gaps, clean up users and groups. The phase most plans underestimate.
• Migrate — test migrations first, then the production run inside a defined window. The test runs matter more than the real one.
• Stabilize — user acceptance, admin enablement, integration re-pointing, and fixing whatever testing missed.

How long it takes

Under 100 users with light customization and few apps: four to six weeks. Mid-market, 500 to 2,000 users with custom workflows and significant Confluence content: three to six months. Enterprise with multiple instances to merge, heavy customization, or strict compliance windows: nine to twelve months.

Those ranges assume someone internal is available to make decisions. The most reliable predictor of a slow migration is not technical complexity. It is the absence of a person empowered to say no, we are not rebuilding that.

What tends to go wrong

• No test migration. Running one migration is a gamble. Running three is a plan.
• Finding out in week nine that an app has no Cloud path. Entirely preventable in week one.
• Migrating the mess. Cloud does not fix a badly governed instance. It relocates it.
• Ignoring integrations. Scripts, webhooks, and reporting tools pointing at old URLs fail quietly and get discovered late.
• Treating training as optional. Cloud navigation and admin differ enough that even experienced admins need time.

Answer these before kickoff

Who owns the go/no-go call. What downtime window is acceptable. Whether you are consolidating instances or moving them as they are. Which edition you are landing on, and why. What done means, in writing.

Get those five answers and the rest is execution.