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. 🙂

[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.