Assess: know exactly what moves before anything does

The deadline says 2029. The arithmetic says now.

Atlassian has fixed Data Center's end dates: sales to new customers stopped in March 2026, existing customers can renew and buy apps only until March 2028, and in March 2029 subscriptions expire and instances go read-only. On paper, that looks comfortable.

Now add the durations. Atlassian's own estimates put a lift-and-shift at roughly four months for up to 5,000 users and roughly six for up to 10,000 — above that it does not recommend lift-and-shift at all, and typical enterprise migrations run 12 to 16 months. A regulated enterprise then adds its own queues before anything moves: security review of Atlassian and of every Marketplace vendor that will hold your data, the DORA pre-contract assessment, change-board approval, agreed change windows. Run that arithmetic backwards from 2029 — with app renewals ending a year earlier — and the assessment belongs in this year's plan. The real decision point has already arrived.

Plan around what the tooling will not move

The Jira Cloud Migration Assistant (JCMA) is genuinely capable inside its scope. It carries project configuration, workflows and schemes, and the issue-level record your auditors care about — comments, attachments, work logs, links and full history. A serious assessment therefore spends most of its time on the other column.

Dashboards and filter subscriptions are rebuilt in Cloud, not migrated. Cross-project boards and filters, webhooks and custom events stay behind. Users arrive without passwords or avatars. Two behaviours matter especially in a bank: accounts are matched on email address, so an unclean directory can attach migrated work to the wrong person; and groups are matched by name, with repeat migrations only ever adding members — a documented permission-escalation risk that makes post-migration access review mandatory. The largest gap of all is Marketplace app data, which moves only where the app's vendor has built a path. The assessment turns each of these into a decision with a named owner — before it can become a cutover-week surprise.

Triage the apps — then migrate less

Apps are where most of the real effort hides, so the assessment triages every installed app four ways: keep, replace, rebuild on native Automation or Forge, or retire — and usage data sends more apps into the retire column than their vendors would predict. Treat the assessment columns with suspicion. A Cloud version existing says nothing about whether your data moves: migration paths run from automated down to "contact vendor", which usually means no data path exists. And "Cloud-compatible" says nothing about parity, so every kept app is checked feature by feature against real usage, because Cloud editions of the same app routinely drop or alter features.

Scripted automation is the honest hard case. On Cloud, ScriptRunner runs as a separate asynchronous service against REST APIs, so scripts are rewritten, not moved — price that workstream on its own line and start it early, because no single item shifts more cutover dates.

Finally, the cheapest de-risking available: migrate less. Archive projects nobody has touched since the last reorg, deduplicate custom fields, standardise near-identical workflows, clear out inactive users — and fix the two items that are mandatory rather than advisory: duplicate email addresses, which Cloud cannot migrate, and same-named groups, which Cloud merges on arrival, access consequences included. Fewer objects means a shorter window, fewer pre-flight failures and a Cloud site that is governable from its first day.

Next step: Evidence

An assessment done properly produces more than a plan. The inventory, the app decisions, the residency questions it raises and the gaps it refuses to paper over are the raw material of the pack your second line and your auditors will ask for. Assembling that pack — vendor-risk records, data-residency mapping, rollback plan, cutover runbook, written before the migration rather than reconstructed after it — is the second of the four steps: Evidence.

Two homepage FAQ answers sit directly behind this step: "What actually happens to Data Center in 2029?" and "How quickly can we get a defensible migration plan?" — both are answered here.