Jira Cloud Migration Plan: 16-Week Roadmap From Assessment to Cutover

9 min read ยท 2026-10-25

A jira cloud migration plan is the step-by-step schedule for moving your Jira Server or Data Center instance to Jira Cloud: what you will move, in what order, who owns each step, how you will test it and when users switch over. For a mid-sized instance, a common shape is about 16 weeks: assess and clean up first, run at least one full test migration, then cut over in a planned window and support teams for the first weeks.

The tool that moves the data, the Jira Cloud Migration Assistant, is the easy part. Migrations slip because of apps with no cloud version, custom fields nobody uses, duplicate user emails, and teams who find out on Monday morning that their dashboards look different. The plan below tackles those early, with owners, milestones and a cutover runbook. Check the current Atlassian migration documentation for your exact versions before you commit to dates, because supported paths and features change.

The roadmap at a glance

Goal: All in-scope Jira projects, users and supported app data running in Jira Cloud, validated by project owners, with the old instance set to read-only and a support plan in place. Duration: 16 weeks

  1. Assess and decide (Weeks 1-3)

    Know exactly what you have and decide what moves, what changes and what stays behind.

    • Inventory projects, issue counts, attachments size, custom fields, workflows, schemes, boards and filters.
    • List every Marketplace app with its owner and usage, and check whether it has a cloud version and a migration path.
    • Map integrations: CI/CD tools, Confluence links, single sign-on, scripts calling the Jira REST API.
    • Choose the cloud plan and edition with procurement, and check data residency needs with security.
    • Decide the migration approach: all at once in one window, or in waves by team or project.

    Milestone: A migration assessment signed off by the sponsor: scope, app decisions (migrate, replace or drop), approach and target cutover window.

  2. Clean up and prepare (Weeks 3-6)

    Shrink and tidy the instance so there is less to move and less to break.

    • Archive or delete projects nobody has updated in a long time, after confirming with their owners.
    • Merge duplicate custom fields and remove unused workflows, screens and schemes.
    • Fix user data: invalid or duplicate email addresses, inactive directories and duplicate group names.
    • Set up the cloud site, verify your domain and configure identity and SSO in Atlassian Administration.
    • Install the Jira Cloud Migration Assistant on the source instance and connect it to the cloud site.

    Milestone: Cleanup complete with a before and after count of projects, custom fields and workflows, and the cloud site connected to the source instance.

  3. Test migration (Weeks 6-9)

    Run a full rehearsal on a test cloud site and find every problem before users see it.

    • Migrate users and groups, then the in-scope projects, to a test or sandbox cloud site.
    • Review the pre-migration checks and the migration report, and log every error and warning.
    • Time each step to estimate how long the real cutover window must be.
    • Ask one or two project owners per department to check their issues, boards, filters, dashboards and automation rules.

    Milestone: A test migration report with every issue logged, owned and resolved or accepted, and a measured cutover duration.

  4. Rebuild, train and communicate (Weeks 8-12)

    Get everything the migration does not carry over ready, and prepare users for the change.

    • Rebuild what does not migrate, such as global settings, unsupported custom fields or app replacements.
    • Reconnect integrations to the cloud site and test each one end to end.
    • Run short training sessions on what changes in Cloud, such as navigation, dashboards and automation.
    • Announce the cutover date, the freeze window and where to get help, at least two weeks ahead.
    • Write the cutover runbook: every step, its owner, its expected duration and the rollback point.

    Milestone: Integrations tested on the cloud site, training delivered to project admins, and the cutover runbook approved by the sponsor.

  5. Cutover (Weeks 13-14)

    Move production data in the planned window and switch users to Cloud.

    • Freeze changes on the source instance and announce the start of the window.
    • Run the final migration of users, groups and projects, following the runbook step by step.
    • Validate with the checklist: issue counts per project, sample issues, attachments, permissions, boards and key filters.
    • Switch integrations and links to the cloud site and set the old instance to read-only.
    • Send the go-live message with the new URL and the support channel.

    Milestone: Production data migrated and validated against the checklist, users working in Cloud, old instance read-only.

  6. Hypercare and decommission (Weeks 14-16)

    Support teams through the first weeks and close the project cleanly.

    • Run a daily support stand-up for the first week and a dedicated help channel.
    • Track and fix broken links, missing permissions and dashboard gaps reported by users.
    • Confirm with each department lead that their teams are working normally.
    • Agree on the archive plan and the decommission date for the old instance with security and legal.

    Milestone: Support tickets back to normal levels, department sign-offs collected and the decommission date approved.

Who owns what

A Jira migration touches every team that uses Jira, so it needs a clear split between the people who move the data and the people who confirm it works. Put names against each role in the kickoff deck.

Project owners matter more than most plans admit. They are the only people who can tell you that a board, filter or automation rule works as before. Book their time for the test migration and cutover weekend early.

  • Sponsor (head of IT or engineering): approves scope, budget, cutover window and app decisions.
  • Migration lead (Jira admin or project manager): owns the plan, the runbook and the test migrations.
  • Jira administrators: cleanup, configuration, rebuilds and the migration runs.
  • App owners: check each app's cloud path, run vendor migration steps and validate app data.
  • Identity or security team: SSO, user provisioning, data residency and access reviews.
  • Integration owners: reconnect and test CI/CD, scripts and other tools.
  • Project owners: validate their projects in the test migration and after cutover.

Example: a filled-in plan for a mid-sized engineering org

Picture a company with one Jira Data Center instance, 120 projects, several hundred users and 25 Marketplace apps. Many projects are old, and a few teams rely on custom scripts.

The team chose a single cutover over a weekend because most projects share boards and filters across teams. Splitting into waves would have broken those links for weeks.

  • Weeks 1-3, assess: 120 projects inventoried, 25 apps reviewed (14 migrate, 6 replaced by built-in cloud features, 5 dropped). Owner: migration lead.
  • Weeks 3-6, clean up: 45 inactive projects archived, duplicate custom fields merged, user emails fixed. Owner: Jira admins.
  • Weeks 6-9, test migration: full rehearsal to a sandbox, 30 issues logged, cutover time measured. Owner: migration lead with project owners.
  • Weeks 8-12, rebuild and train: CI/CD integration reconnected, three training sessions for project admins, runbook approved. Owner: Jira admins and integration owners.
  • Weeks 13-14, cutover: freeze Friday evening, migration and validation over the weekend, go-live Monday. Owner: migration lead.
  • Weeks 14-16, hypercare: daily stand-ups, department sign-offs, decommission date set. Owner: migration lead.

What to check before you migrate

The Jira Cloud Migration Assistant moves most project data, including issues, comments, attachments, workflows, boards and sprints. It runs pre-migration checks and gives you a report. Some items do not move the same way, such as global settings, some custom field types from apps, and certain user details. Read the current Atlassian list of what is and is not migrated for your version before you finalize scope.

Apps are usually the biggest open question. For each one, check whether a cloud version exists, whether the vendor supports an automated migration path, and whether Cloud already has a built-in feature that does the same job. Write the decision down with an owner, because a missing app discovered at cutover can block a whole team.

  • Users with missing, invalid or duplicate email addresses.
  • Custom fields and workflows that are duplicates or unused.
  • Apps with no cloud version or no migration path.
  • Scripts and integrations that call the server REST API directly.
  • Very large attachments or projects that will lengthen the cutover window.
  • Data residency or compliance needs for the cloud site location.

How to write the cutover runbook

The runbook is a numbered list of every step in the cutover window, in order. Each row has the step, the owner, the planned start time, the expected duration from your test migration, and a check that confirms the step is done. Keep it in a shared sheet or a Confluence page that everyone on the call can see.

Add a go or no-go checkpoint after validation. If issue counts or permissions fail the checklist and cannot be fixed in the window, you need a clear decision on who calls a rollback. In a rollback, users go back to the source instance, which stays untouched until you confirm Cloud is ready.

  • Freeze the source instance and notify users.
  • Take a full backup of the source database and attachments.
  • Migrate users and groups, then projects, in the order tested.
  • Run the validation checklist with project owners.
  • Go or no-go decision by the sponsor.
  • Switch integrations, set the source to read-only and send the go-live message.

How to present it to leadership

Leadership cares about three things: when teams will be on Cloud, how much disruption to expect, and what could go wrong. Show a one-slide timeline with the six phases, the cutover date and the freeze window. Add the app decisions in one line (migrate, replace, drop) and the top risks with an owner each.

Leave out field-level details and the full app list. Give leadership the number of projects in scope, the number archived during cleanup and the result of the test migration. A rehearsal that found and fixed problems is reassuring. Report it as proof the plan works.

Risks and dependencies

Most risks show up in the assessment and the test migration, which is why those phases come first. Keep a risk log with an owner and a fallback for each item, and review it weekly.

Watch the calendar too. Avoid a cutover during a release, a quarter-end close or a period when many people are on leave, because you need project owners available to validate.

  • Critical app has no cloud migration path: owner is the app owner. Fallback: replace it with a built-in feature or another app, and export the data before cutover.
  • Test migration takes longer than the planned window: owner is the migration lead. Fallback: migrate users and archived projects ahead of time, or split into waves.
  • SSO or user provisioning issues on go-live: owner is the identity team. Fallback: test sign-in with a pilot group before cutover.
  • Integrations fail after cutover: owner is each integration owner. Fallback: tested reconnection steps in the runbook.
  • Teams resist the new interface: owner is the migration lead. Fallback: training, quick-reference guides and office hours in hypercare.

Common mistakes to avoid

  • Migrating everything as it is moves years of clutter to Cloud, so archive inactive projects and merge duplicate fields before the first test.
  • Leaving app decisions to the end can block a team at cutover, so review every app in the first three weeks and record a migrate, replace or drop decision.
  • Skipping the test migration means you discover errors on the production weekend, so run at least one full rehearsal to a test site.
  • Guessing the cutover window leads to an overrun on Monday morning, so time every step during the test migration and add a buffer.
  • Validating only issue counts misses broken boards, filters and permissions, so have project owners check their real daily views.
  • Decommissioning the old instance too early leaves no fallback, so keep it read-only until departments have signed off.

Frequently asked questions

How long does a Jira cloud migration take?

It depends on instance size, the number of apps and integrations, and how much cleanup you need. Small instances can move in a few weeks, while larger ones often take several months. The assessment and test migration give you a realistic estimate.

What does the Jira Cloud Migration Assistant migrate?

It moves users and groups, projects, issues with comments, attachments and history, workflows, boards and sprints, and many custom fields. Some items, such as global settings and some app custom fields, do not migrate. Check Atlassian's current list for your version before you plan.

Should we migrate all Jira projects at once or in waves?

A single cutover is simpler when projects share boards, filters or users, because links stay intact. Waves work better for very large instances or teams with different readiness. The test migration usually shows which approach fits.

How do you migrate Jira apps to Cloud?

List every app, check if it has a cloud version and an automated migration path from the vendor, and decide to migrate, replace or drop it. Some app data moves with the migration assistant, while others need vendor tools or manual steps. Test each app's data in the test migration.

Can we roll back a Jira cloud migration?

Yes, if you plan for it. Keep the source instance untouched and frozen during cutover, take a full backup, and set a go or no-go checkpoint in the runbook. If validation fails, users return to the source instance while you fix the issues.

Generate this roadmap with AI