Cut over: downtime engineered, not endured

The change window carries only the delta

By the night of the cutover, most of the estate has already moved. Users and groups go across in advance with zero downtime. Attachments — typically the longest-running part of any Jira migration — start transferring weeks before the date, and because each later run skips whatever has already arrived, the final pass is a fraction of the whole. What the change window actually carries is the delta: everything created or changed since the last pre-migration run.

Inside the window, the source goes effectively read-only — a browse-only permission scheme, with site-wide banners so nobody is left guessing — the delta migrates, and verification completes before a single user is invited in. The runbook is not improvised on the night: its steps carry named owners and timings measured in rehearsal, because Atlassian publishes no downtime estimate and your own test runs are the only benchmark worth presenting to a change board. Rollback, meanwhile, is genuine rather than ceremonial: the old instance remains untouched and read-only until you formally stand it down.

Cohorts, configuration drift and freeze discipline

A bank-sized estate rarely moves in one night. We cut over in cohorts — division by division, or the active estate separately from archived material — so every window stays short and every verification stays tractable. Phasing has hard constraints that are respected, not negotiated: Advanced Roadmaps plans must travel together with their associated projects, and some apps require every dependent project in the same wave.

The documented risk of a phased migration is configuration drift — the source evolving between waves until the two platforms quietly disagree. The control is a short configuration freeze between phases: agreed up front, communicated like any other change control, and treated as the price of phasing rather than a surprise discovered mid-programme.

Launch and hypercare: landing the users, not just the data

Data arriving is not the migration succeeding. JCMA does not invite your users — you do, with communications, quick-start guidance, office hours and a visible support channel ready before first login. Then hypercare runs until steady state, and it has a concrete worklist rather than a vague promise to "monitor":

• Group memberships, recertified. On re-migration JCMA only ever adds members to matching Cloud groups — it never removes them — so a user taken out of a privileged group on the source can still hold it in Cloud. Post-migration group review is mandatory, not optional.
• Links, re-pointed. Product links are fixed with Atlassian Administration's link-fixing tools so cross-references keep resolving.
• Dashboards and subscriptions, rebuilt. Neither migrates; both are recreated deliberately rather than reported missing.
• Integrations, re-keyed. Entity IDs change in Cloud, and Atlassian provides an API for the server-to-cloud ID mappings — exactly what re-keying needs.

Steady state is declared by your admins, not by the data arriving — and the closure is itself a change record: verification documented, evidence pack archived.

Next: steady state — and what comes after

Cut over ends the sequence — Assess, Evidence, Rehearse, Cut over — but not the responsibility. Once hypercare stands down, the work shifts from migrating to governing: audit-log exports flowing, access reviews honest, and the platform earning back what the business case promised. If the go-live felt quiet, that is the point — the three steps before this one are why. And if your sequence has not started yet, Assess is where it begins.

This page expands what two homepage FAQ answers promise — on migrating without breaking change control and audit, and on disruption limited to short, planned cutover windows. Both are answered here.