Looking for Proven Cloud-to-Cloud Migration Plan / Documentation (Project-Level)

[Biancha]

Hi everyone,

I’m hoping someone in the community may be willing to share a proven approach, checklist, or documentation template for Jira Cloud-to-Cloud migrations.

Most of the guidance I’ve found focuses heavily on Server-to-Cloud, but our scenario is different.

We frequently acquire new products, and as part of that process we migrate them from their legacy Jira Cloud instance into our main Jira Cloud instance.

A few key points about our situation:

• This is not usually a full-site migration

• We typically migrate selected projects only

• We need to retain:

  • All issues

  • Attachments

  • Relevant configurations (where practical)

• We are not always bringing across all users or global configurations

I’m particularly interested in:

• A repeatable migration framework or governance model

• Pre-migration discovery checklists

• Lessons learned / pitfalls to avoid

• Best practice for project-level Cloud-to-Cloud migrations

If anyone has documentation, a structured runbook, or even high-level process guidance they’re willing to share, it would be greatly appreciated.

Thanks in advance - keen to learn from others who have navigated this at scale.

[Matthias Gaiser _K15t_ · Accepted solution]

Hey @Biancha

we're developing an app for synchronizing work items across Jira instances. I don't have specific runbooks at hand, but some thoughts which I can offer.

In the context of our app, I got to know some of our customers which are using the native copy functionality to copy selected projects between Jira Cloud instances which is located in the Atlassian Administration > Data management > Data transfer.

Have you used that method in the past?

You can select which projects you want to migrate and also have different options for copying the users. However, as far as I understand it, at the minimum it copies all users and groups which are referenced in your project. Would that work for you - or what would be your ideal scenario about the user mappings?

[Biancha]

Thanks @Matthias Gaiser _K15t_

I have only done the migrations via csv imports in the past. Which is quite seamless, however the attachments are the problem as that is a complete different step. 

I am going to look into this method today, to see whether or not I can make it work, worst case scenario we can just remove the additional users after import.

Thank you for sharing

[Arkadiusz Wroblewski · Accepted solution]

Hi

@Biancha 

We’re in a very similar spot (Cloud → Cloud, usually selected projects, not full-site). What’s worked for us is treating this as a repeatable runbook with governance + batching, not a one-off “migration event”.

Our repeatable approach:

1.  Intake + scope lock
2. Confirm exact projects in scope (and whether they’re company-managed vs team-managed)
3. Define what must be preserved (issues, attachments, history, boards/sprints, etc.)
4. Decide user strategy early: only in-scope users vs “bring everyone”

2) Discovery checklist (per project)

1. Volume: issues + attachment size (this drives timelines/risk)
2. Custom fields, workflows, screens used by those projects
3. Boards/sprints, automation rules, components/versions
4. Filters/dashboards and who owns them
5. Marketplace apps used in the source projects (this is the #1 surprise area)

3) Target readiness (“landing zone”)

• Pre-align group naming / permission model so permissions don’t become a mess
• Decide what config you’ll reuse vs rationalize (avoid importing everything blindly)

4) Execution

• Use Atlassian’s Cloud-to-Cloud “copy Jira data” / copy plans and batch projects (multiple smaller plans).
• Always do a pilot first with a “worst case” project (attachments + workflows + boards).

5) Validation + cleanup

• Spot-check issue counts, attachments, links, boards/sprints
• Validate permissions for key personas (admins, delivery teams, externals)
• Confirm Marketplace app behavior/data
• Post-migration cleanup: group consolidation, filter/dashboard ownership, deprecate legacy access

Pitfalls we’ve learned to avoid:

• Team-managed projects can behave differently—flag them early.
• Marketplace apps often need separate steps (or don’t migrate cleanly).
• Big single copy plans are painful to troubleshoot; small batches are much easier.
• Users/groups: if you don’t control it, you’ll inherit a mess—plan cleanup as a standard step

[Matthias Gaiser _K15t_]

Impressive list @Arkadiusz Wroblewski. Welcome to the Atlassian Community and thank you for sharing your knowledge.

[Arkadiusz Wroblewski]

Greetings @Matthias Gaiser _K15t_  and Thank You :)

[Biancha]

Hi @Arkadiusz Wroblewski,

Very detailed and exactly what I was after, I will work through this properly today. Appreciate you taking the time to share this!

[Luka Hummel - codefortynine · Accepted solution]

Hi @Biancha

If you are encountering Atlassian's Cloud-to-Cloud migration feature that previous answers by @Matthias Gaiser _K15t_ and @Arkadiusz Wroblewski have suggested or is not flexible enough for your purposes I want to suggest giving our app Deep Clone for Jira a try.

Acquisitions and partial Cloud-To-Cloud migrations is a common use case for our Instance Clone feature and has even been used by Atlassian for that.

[Biancha]

Thanks @Luka Hummel - codefortynine

I will take a look at this as well. 

[Biancha]

@Luka Hummel - codefortynine I will connect with you over LinkedIn - I have some questions about the app. 🙂

[Ammara Amir]

Hey, totally get where you're coming from. We ran into the exact same gap last year when our parent company acquired two smaller SaaS products, both sitting on their own Jira Cloud instances. Almost every guide out there assumes you're coming from Server or Data Center, so cloud-to-cloud with only selected projects is a weirdly under-documented space.

A few things that actually saved us during those migrations, sharing in case it helps:

1. Do a full audit of the source instance before touching anything. Custom fields, workflows, screen schemes, and automation rules are where things quietly break. We built a simple spreadsheet mapping every custom field from source to target, and flagged the ones with the same name but different context. That alone caught around 40 percent of the issues we would have hit post-migration.

2. Use the built-in Jira Cloud Migration Assistant for project-level moves, but do a dry run into a sandbox site first. Attachments and issue history come across fine in most cases, but linked issues across projects you're not migrating will break. Decide early whether to bring those parent projects in read-only mode or archive the links.

3. Users and permissions are usually the messiest part. Since you're not always bringing all users, we ended up creating a "migration service account" that temporarily owns orphaned issues, then reassigning post-migration based on a mapping file HR helps us prepare. Saved us a lot of "who is this reporter" cleanup later.

4. Freeze the source instance for at least 24 hours during cutover. Sounds obvious, but the first time we skipped this, someone logged a ticket during migration and it never made it across.

5. Document a rollback plan even if you never use it. For cloud-to-cloud this basically means keeping the source instance untouched for 30 days post-migration before deprovisioning.

On the framework side, honestly nothing beats building your own runbook after the first migration. We wrote ours up as a repeatable acquisition-migration playbook, and if you want a broader view of how we approach cloud migration services across different project types, that piece covers the strategic side of it fairly well.

Happy to answer anything specific if you hit a wall on a particular step. Good luck with it.

[Matthew Joslin_AppFox_]

Great playbook in the accepted answers - the discovery checklist especially.
One step worth adding before execution: a cleanup pass on the source projects.

Selective Cloud-to-Cloud migrations in Jira bring across whatever config the in-scope projects touch, so that means unused custom fields, stale automation, and orphaned schemes.

If you're looking to catch them first in that audit layer described above, Optimizer for Jira works well. It surfaces which fields, workflows, and schemes your migrating projects actually use versus what's dead weight. With frequent acquisitions, that also stops your main instance accumulating duplicate fields with every migration.

It sits alongside the native copy tool or something like Deep Clone. It's about deciding what should move, not having to do the laborious manual move itself.
Free trial if you want to run the audit first: Optimizer for Jira

[Dr_ Ankita Mehta-OpsHub_ Inc]

Hi @Biancha

First of all, I am wondering that how could I miss answering such a meticulous question and reading some of the best answers. The answers shared above are really useful, especially the points around using Atlassian’s Cloud-to-Cloud copy capability and treating this as a repeatable runbook.

Just adding one more angle from the execution side, since selective Cloud-to-Cloud migrations can get tricky when acquisitions are frequent.

A few things I would keep as part of the runbook:

• Lock the scope early: Confirm which projects, issue types, boards, attachments, and configurations need to move.'
• Plan user mapping upfront: Decide how active, inactive, and historical users should be handled before the first test run.
• Validate context, not just counts: Check comments, attachments, issue links, parent-child relationships, history, and field mappings.
• Run migrations in phases: Pilot one complex project first, then move in smaller batches with clear validation checkpoints.
• Keep post-migration cleanup standard: Review permissions, filters, dashboards, groups, and legacy instance access after each move.
• Downtime and disruption: One of the most important deciding factors is to choose a migration tool that allows your source and target systems to be active until the final cutover. Additionally, business continuity should be maintained.

In your case, you may also want to explore an enterprise data migration platform, OpsHub Migration Manager , an Atlassian Solutions Partner, supports phased or full Jira migrations and is useful when teams need to move selected projects without downtime, disruption, or data loss while preserving data fidelity- comments, attachments, relationships, history, and field mappings. Migrate projects of all sizes whether 10 or 1000+ projects without slowing down the end systems. Also, it keeps both source and target systems active and aligned until the migration is complete.

Hope it helps!

All the best for your migration journey!

[Support Application]

Cloud to Cloud is trickier than most people expect because the native tooling has limitations. Here's a practical runbook we use:

Phase 1 — Discovery

• Map all projects, spaces, users, groups, and apps across both instances.
• Identify naming conflicts — duplicate project keys, space keys, usernames.
• Document all automations, webhooks, and integrations on the source.

Phase 2 — Preparation

• Use Atlassian Admin > Data Management > Data Transfer for project-level moves where possible.
• For full site consolidation, plan user deduplication carefully — merged orgs often have the same users on both sides.
• Align permission schemes before migration, not after.

Phase 3 — Execution

• Migrate in batches by team or department.
• Freeze the source instance (read-only) during each batch.
• Validate after each batch before moving to the next.

Phase 4 — Validation

• Check parent/subtask relationships, linked issues, and attachments.
• Retest all automations on the target instance.
• Have a rollback plan for the first 48 hours post-cutover.

We specialize in Cloud to Cloud migrations at Citala Technologies — happy to discuss your specific setup.