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?

[Alan Bruce]

@Kvitka Martsynyshyn 

Well-done article and a great starting point for anyone beginning this journey.

We moved from Data Center to Cloud about 2½ years ago. We had a third party handle the bulk of the migration, and then we had to massage the environment quite a bit afterward.

One important consideration that I didn’t see mentioned is Jira Assets, particularly if you use Assets custom fields. Those did not come over seamlessly for us. Maybe that has improved over the past 2½ years, but based on past experience, I’d definitely validate that portion of the migration carefully.

If I had the opportunity to do it over again, I would have pushed harder for rebuilding more of the environment from scratch rather than simply migrating what we had. We had several existing processes that could have been improved, and the move to Cloud would have been a good opportunity to rethink them.

We’re a small-to-medium-sized organization, though, so the right approach will depend heavily on the size, complexity, and maturity of your current environment.

[Matthew Sinclair]

Great read!

Question - is Field duplication still a problem?

Something we faced when migrating from Site (Cloud) to Site (Cloud) or even DC to Cloud.

Deep Clone app seems to help to a point - but it struggles a little on some JSM nuances.

[Kvitka Martsynyshyn]

@Alan Bruce Thanks for adding this — and congrats on getting through a Data Center to Cloud move!

Great callout on Jira Assets — that's a common gap I didn't cover, and worth its own deep dive. Asset custom fields and object relationships often need separate handling rather than assuming they'll ride along with the project migration. Good to know it's still worth validating carefully.

Your point about rebuilding vs. lifting-and-shifting really resonates too — the migration is often one of the few natural checkpoints to rethink workflows, not just move data. Easy to miss when you're focused on not losing anything.

Appreciate you sharing the small-to-medium org lens as well — that calculus definitely shifts with scale. Thanks for the real-world detail!

[Kvitka Martsynyshyn]

@Matthew Sinclair Yes, still a real issue — especially Cloud-to-Cloud and DC-to-Cloud.

It usually comes down to matching logic: if field name, type, description, or context don't line up exactly on both sides, the target creates a new field instead of mapping to the existing one — repeated/staggered migrations from the same source compound this fast.

What helps most: audit and align field configs before migrating, and do one clean pass rather than iterating repeatedly against the same target.

On JSM — agreed, that's where general tooling (Deep Clone included) tends to need manual reconciliation, since request types and portal configs aren't purely custom-field objects.

If you're already sitting on duplicates, a scoped cleanup (map old→new, bulk-update values, archive orphaned fields) is usually faster than trying to prevent it after the fact.