Moving a Jira Service Management Project to a New Instance: A Practical Overview

[#1]

Migrating a Jira project between instances sounds simple until you actually try it. Issue keys, workflows, custom fields, attachments, and history all need to survive the trip — and Jira doesn't give you a single "move project" button that handles everything cleanly. This post walks through the realistic options, what each one preserves (and loses), and how to plan the move so you don't end up with a half-migrated mess.

First, define ‘instance’

The right approach depends heavily on what kind of transition you're doing:

• Cloud to Cloud (different Atlassian sites)
• Server/Data Center to Cloud (a cloud migration)
• Server/Data Center to Server/Data Center (different hosting, same deployment type)
• Cloud to Server/Data Center (rare, but happens with compliance-driven moves)

Each path has different tooling available, so pin this down before you pick a method.

Option 1: Atlassian's built-in Cloud Migration Assistant

If you're moving Server/Data Center → Cloud, this is the tool Atlassian actually wants you to use. It's built specifically for this scenario and handles:

• Issues, comments, attachments, and history
• Users and groups (with mapping)
• Workflows, screens, and field configurations
• Project and issue-level permissions

It runs as an app inside your Server/Data Center instance and walks you through selecting projects, mapping users, and validating the migration before you commit. For anything beyond a handful of small projects, this is the recommended route — it's actively maintained and understands Jira's internal data model far better than a manual export/import ever will.

Limitations: it's one-directional (on-prem to cloud), and very large instances may need to migrate in batches to avoid timeouts.

Option 2: Project export/import (Server/Data Center only)

For Server-to-Server or Data-Center-to-Data-Center moves on compatible versions, Jira has a native project export feature (Administration → System → Import & Export → Backup/Restore, or project-level XML export depending on version).

This preserves:

• Issues, comments, and attachments
• Workflow and scheme associations
• Issue history

It's finicky about version compatibility, and custom field configurations, automation rules, and third-party app data typically don't come along for the ride — you'll need to recreate those manually on the target instance first.

Option 3: CSV export/import

The blunt-force option, useful when the two instances are too different for a native migration (e.g., different Jira versions, or you only need a subset of fields).

What survives: issue fields you explicitly map — summary, description, status, assignee, custom fields you've included in the export.

What doesn't survive natively:

• Original issue keys (new issues get new keys unless you use the ‘Retain existing project’ trick with a matching project key on the target, which only works if the target project doesn't already have issues)
• Attachments (Jira's standard CSV importer doesn't bring these — you'll need a third-party app or a scripted solution)
• Comment history as distinct entries (you can concatenate comments into a text field, but you lose per-comment authorship and timestamps unless you use a more advanced importer)
• Issue links and epic/sub-task relationships (need careful field mapping to reconstruct)

CSV is best treated as a last resort or a supplement — good for getting the bulk of the data across, but expect manual cleanup afterward.

Option 4: Marketplace migration apps

Marketplace migration apps exist specifically to handle cross-instance moves with more fidelity than CSV, including configuration (workflows, screens, custom fields) alongside the data. Worth evaluating if:

• You're moving many projects at once
• You need configuration parity, not just issue data
• Built-in tools don't support your specific instance combination (e.g., Cloud to Cloud)

Pricing and reliability vary, so pilot with a low-stakes project first.

What to check before you migrate, regardless of method

• Custom fields: confirm the target instance has matching field types and IDs, or your data will land in the wrong place or get dropped.
• Workflows and schemes: recreate or import these on the target before moving issues, so statuses map correctly.
• Users and groups: decide how you'll map or invite users, especially across Cloud sites where account IDs differ.
• Issue keys: if key continuity matters (for external references, integrations, or muscle memory), only the Cloud Migration Assistant and native XML backup reliably preserve them.
• Attachments and comments: verify your chosen method actually carries these — this is the most common thing teams discover missing after the migration.
• Integrations: anything pointing at the old project (Confluence links, CI/CD, Slack notifications, automation rules) will need to be repointed to the new instance/project.
• Permissions: don't assume they'll match — permission schemes often need to be rebuilt.

A sane migration sequence

1. Audit the source project — field usage, workflow states, automation rules, integrations, and open issue count.
2. Set up the target instance's configuration first — workflows, schemes, custom fields — so incoming data has somewhere correct to land.
3. Run a test migration with a small subset of issues to validate mapping before committing to the full set.
4. Freeze the source project — lock it to read-only or pause work briefly during the actual cutover to avoid data drift.
5. Migrate, then spot-check: pull a sample of issues and manually verify fields, attachments, comments, and links.
6. Repoint integrations and tell the team the new project location.
7. Keep the old instance/project archived (not deleted) for a defined retention period in case something surfaces later.

Bottom Line

If you’re moving from Server or Data Center to Cloud, the Cloud Migration Assistant is generally the easiest place to start since it’s built specifically for that path.

For migrations between the same deployment types, native export/import can work if your versions are compatible. Otherwise, CSV exports or Marketplace apps can be useful alternatives, although they may require a bit more manual cleanup afterward.

One thing I’d definitely recommend is setting aside time for validation. Even when the migration itself goes smoothly, it’s worth checking that the data and relationships you rely on have transferred as expected.

Curious to hear from others who’ve gone through this — which migration approach worked best for you, and what would you do differently next time?