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