The execution playbook that picks up where the planning guide ends: tooling, checklists, timelines, and the traps that stall real migrations. Part two of two.
Two guides, one migration. This is the execution playbook — tooling, checklists, and the cutover itself. Still deciding whether and when to move? Start with the planning guide.
Atlassian ended support for Server on February 15, 2024. Since then, every self-hosted team has been living with one of two plans: stay on Data Center deliberately, or move to Atlassian Cloud eventually. This guide is for the second group — the complete, execution-level companion to our shorter Cloud migration planning guide. That one covers what to decide. This one covers what to do.
Everything here is drawn from Atlassian’s official migration documentation — primarily the Jira pre-migration checklist and the migration resource library — plus the field notes you only collect by running these projects. Where Atlassian has a doc worth reading in full, we link it. Where the docs are quiet, we say so.
Our planning guide breaks a migration into four phases: assess, remediate, migrate, stabilize. Nothing below changes that model — it fills it in. Assessment and remediation are where the calendar goes. The migrate phase should be a well-rehearsed weekend. Stabilization is where you find out how honest your testing was.
One vocabulary note before we start: in Cloud, Jira issues are now called work items. Atlassian’s docs use both terms. So will your users, for about a year.
Atlassian’s free migration assistants do the heavy lifting. The Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant install on your Data Center instance, assess your users and apps, run pre-migration checks, and move projects, spaces, users, groups, and attachments to your cloud site. Bitbucket has its own assistant.
Two constraints to know up front. First, the assistants only run on supported Data Center versions — if your instance is old enough, a platform upgrade is step zero. Second, the assistant reviews your data for common errors, but it does not check for everything. That is exactly why Atlassian publishes a manual pre-migration checklist alongside it, and why most of this guide exists.
A timing tip that saves entire weekends: users, groups, and attachments can be migrated in advance of your production window. Attachments are usually the bulk of the transfer. Move them early and your cutover shrinks from a data problem to a verification problem.
For eligible migrations, Atlassian also runs FastShift, a program that accelerates cloud adoption with dedicated support from Atlassian’s own migration team. Worth asking about early.
Ask anyone who has run a few of these: the data moves fine. The users are the hard part. Atlassian devotes an entire documentation section to user migration, and it earns the attention. Work through these before anything else:
Identity tooling has its own sequencing. If you need single sign-on or SCIM provisioning, that runs through Atlassian Guard — and Guard Standard should be configured before you migrate, not after. Two traps from the checklist worth repeating: if your identity provider carries two addresses per user (a UPN plus an email) on approved domains, set it to identify users by email, or the same person can arrive in Cloud twice. And if you run Guard Premium, its content scanning inspects each work item as it lands — on a large migration that can generate an avalanche of sensitive-data alerts, so consider temporarily switching off detections you do not need during the run.
Finally, sequence matters: migrate users and groups before everything else, then review which groups picked up product access on the way in.
We said it in the planning guide and it stays true here: Marketplace apps are where migration timelines go to stretch. Start the app audit in week one. The assistants include an app assessment that shows which of your installed apps exist in Cloud, but existence is not parity — and the app existing says nothing about the app’s data.
App data moves only when the vendor has built a migration path, and those paths range from automated to reconfigure-by-hand. Contact each Marketplace Partner whose data you need. For the heavyweights, Atlassian maintains app-specific guidance — ScriptRunner, Xray, and Zephyr Squad each get their own pages, which tells you something about how often they complicate migrations. Some vendors also support preloading app data ahead of the main event.
The honest move is to treat the audit as a subtraction exercise. Every app carries a Cloud license priced at your full user tier. If nobody can name who depends on it, this is the moment it leaves the stack. Our governance guide covers the cleanup discipline in detail, and it applies double before a migration — Cloud does not fix a badly governed instance, it relocates it.
The Jira pre-migration checklist runs twenty-four items, and Confluence has its own. These are the ones that stop real migrations.
The account running the migration needs system admin on Data Center, an account on the target cloud site, the org admin role in Cloud, write access to the Jira home export directory, and Browse Projects permission on every project selected. Miss one and the pre-flight checks will let you know, usually at the least convenient moment.
Two smaller checklist items earn a mention here. Your cloud site should run the same products and the same language as your Data Center instance, or users, groups, and some fields will not land cleanly. And if you use Jira Align, loop in its support team early — it has extra steps before, during, and after the migration.
Atlassian strongly recommends a test migration before the production run. Our position from the planning guide stands: one migration is a gamble, three is a plan. A proper test cycle looks like this:
One staging trap from the checklist that catches even careful teams: if you clone production data into a staging environment for test runs, save the staging instance’s Server ID first and restore it after the clone. Otherwise staging starts impersonating production in ways that get confusing fast.
And if your production migration will run over a weekend or holiday, or involves more than 1,000 users, tell Atlassian’s migration support team one to two months in advance so they can have extra support on hand. It is the cheapest insurance in this entire project.
By now the production run should be a rehearsal of something you have already done three times. The playbook:
If the window is tight, Atlassian’s downtime-reduction guidance is worth a read — most of it amounts to moving attachments and users early and staging the work in waves.
The migration is done when your users say it is, not when the progress bar does. The post-migration tasks that matter most:
The ranges from our planning guide hold: four to six weeks for a small, lightly customized instance; three to six months for mid-market with real workflow and Confluence estates; nine to twelve months for enterprises consolidating instances under compliance constraints. The variable that moves those numbers most is still decision-making speed, not data volume.
On licensing: you will run Data Center and Cloud in parallel during the transition, and Atlassian offers cloud migration trials to Data Center customers to take the sting out of the overlap. Confirm you have enough cloud licenses for everyone you intend to migrate before migration day, and pressure-test the edition choice against what you actually use — our licensing guide and licensing practice exist because that decision is worth real money.
And the caveat a trusted advisor owes you: not every team should migrate this quarter. Regulatory constraints, an app estate with no Cloud path, or a contract cycle that punishes mid-term changes are all legitimate reasons to keep running Data Center well a while longer. The right answer is the one you can still defend in twelve months.
Sync and assess users. Audit apps in week one. Work the checklist — heap, database pool, firewall rules, character limits, Assets counts, duplicate names, public access. Test until the timing is predictable. Move attachments early, freeze, run, verify. Fix links and integrations, enable admins, keep the old instance read-only. Nothing on that list is exotic. All of it is work.
Plenty of teams run this playbook themselves with Atlassian’s tooling and the checklists above. Bring in help when the shape changes: multiple instances to consolidate, a heavy app estate, a hard compliance window, or simply nobody internal with the calendar to own it.
Avaratak is an accredited Atlassian Solution Partner, and our cloud migration practice is staffed exclusively by senior consultants — five-plus years on the platform, every one of them. We run test migrations until they are boring, because boring is the goal. If a second set of eyes on your plan would help, book a discovery call — thirty minutes, no theater, and you keep the plan either way.
Bookmark these. They are the source of truth this guide is built on:
Guides only take you so far. Bring the messy specifics and we will tell you what we would actually do.
.webp)