Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How to Build a Cloud Migration Playbook for Jira and Confluence

Moving from Data Center or Server to Atlassian Cloud can feel overwhelming at first. There are multiple teams to align, technical hurdles to plan for, and a lot of details to get right. The good news is that with the right playbook in place, the journey becomes a lot smoother. A migration playbook is essentially your guidebook that documents the plan, timelines, responsibilities, and lessons learned.

Here is a practical approach to building one for Jira and Confluence.

 

Step 1. Assess your current setup

Start by taking stock of what you have today. Document your Jira projects, Confluence spaces, workflows, custom fields, and apps. This is where you identify what is truly needed in the cloud and what can be cleaned up. For example, unused workflows or duplicate fields can be retired instead of migrated. A leaner system makes for a cleaner migration.

 

Step 2. Define the migration scope

Decide what will move and when. Some organizations take a big bang approach, moving everything at once. Others prefer a phased approach, starting with a pilot project or a single department. Document this decision in your playbook along with the reasoning. This helps everyone understand the scope and prevents scope creep later on.

 

Step 3. Engage stakeholders early

Migration is not just an IT project. It affects project managers, developers, knowledge workers, and leadership. Identify stakeholders from each group and make them part of the planning process. Use Confluence to create a shared migration space where updates, FAQs, and timelines are posted. This transparency builds trust and reduces surprises.

 

Step 4. Test with a pilot

Before migrating everything, run a pilot migration. Choose one or two Jira projects and a few Confluence spaces. This pilot helps uncover issues such as data inconsistencies, app compatibility, or unexpected downtime. Document what went well and what did not in the playbook. These lessons will shape the larger rollout.

Step 5. Build your migration runbook

The runbook is the action plan for the actual migration day. It should outline the exact steps to take, who is responsible for each step, what communication goes out to users, and how you will validate the success of the migration. Include fallback plans in case something does not go as expected.

Step 6. Train and support users

Even with a technically flawless migration, users will have questions about new interfaces or changed workflows. Build training into your playbook. Short how to videos, Confluence guides, and office hours sessions can make adoption much easier.

Step 7. Measure success

After migration, track key success metrics such as system performance, user adoption, and support tickets raised. Compare them against expectations. Document the results in your playbook so that future migrations within the organization benefit from this knowledge.

Final thoughts

A cloud migration is a journey but it does not have to be chaotic. By creating a clear playbook with assessment, scope definition, stakeholder engagement, pilots, runbooks, training, and success measures, you give your organization a structured path forward. More importantly, you build confidence across teams that the move to cloud will unlock long term value.

7 comments

s_gridnevskii
Contributor
September 9, 2025

I think step 0 would be to assess custom modifications and plugins. We have dozens of groovy scripts and a couple of hundreds automation rules. Additionally there are important plugins which we cannot stop using just because they are absent in cloud. Finally we should check if we can migrate Assets with no losses (especially history of objects) since we rely on them.

Like Sai Krishna likes this
Sai Krishna
Contributor
September 9, 2025

I absolutely  agree with you @s_gridnevskii  . In step 1 , when I say "Document your Jira projects, Confluence spaces, workflows, custom fields, and apps" , I mean analyzing your current apps , automations , dashboards  and anything that are not migrated. We need to manually address these using custom scripts and using REST APIs. 

Like s_gridnevskii likes this
s_gridnevskii
Contributor
September 9, 2025

Yes. And after assessment you may decide that you will not migrate and stay on datacenter until 2029 and then switch to something else.

Like Sai Krishna likes this
Jonas Pencke
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 9, 2025

@s_gridnevskii and then? You end up with the same pain and vendor lock-in — just replacing A with random B — and on top of that, you also lose all your historical data.

From our experience doing quarterly migrations of hundreds of projects from DC to Cloud, it’s definitely a complex task and you sometimes have to cut corners. But the reality is that most of our plugins are either available on Cloud, or the functionality is already natively included.

It’s also often a good opportunity to revise project configurations and processes, especially for projects that have been running for a long time. We consistently find tremendous optimization potential — simplifying complexity and better aligning the setup with how teams are actually working today.

And don’t forget about all the advantages you gain on the Cloud platform: additional features, lower hardware costs, and reduced operating effort for your teams.

Like # people like this
s_gridnevskii
Contributor
September 10, 2025

@Jonas Pencke yes you are right, some processes are suboptimal in terms of IT. But we cannot stop business just because IT engineers don't like something. And company cannot spend $$$ just because someone pushes us to migrate.

Perhaps yes, we have enough time until 2029 to create a strategy and migrate to something opensource. If it is Atlassian - fine. If not - we will see. Maybe I will find another job :)

 

Mathew Lederman
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 10, 2025

I'll add a few steps for you:

Step 0: Make no changes. Perform a cloud migration to a dummy site. See what breaks.  

Step 0.1: Assume all plug-ins will not function the same, break usage, or simply not exist in the Cloud. Use your dummy site to test and plan accordingly.

Step 0.2: Assume Cloud JSM is awful and plan workarounds for every piece of functionality native to Datacenter. Use your dummy site to test and plan accordingly.

Like Sai Krishna likes this
Sai Krishna
Contributor
September 10, 2025

hi @Mathew Lederman  , that’s such a cool approach , doing a dummy migration first and testing everything will a game changer. Definitely going to help us plan better. Love how this community always shares unique ideas like this!

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events