Maybe you're on Data Center and looking to move to cloud. Or maybe you're already in a cloud environment, you've acquired another company, and you need to merge your cloud instances. Either way, here's a high-level overview of what you can expect to think about as you prepare for your cloud journey.
Most Atlassian customers are already on that journey. Atlassian says 99% of its customers are in cloud or on a path there, including 75% of regulated and enterprise customers.
Keep in mind that no two migrations are the same. A variety of factors create nuance and differences between every migration. This Atlassian cloud migration checklist only scratches the surface. It covers the high-level details to settle as you prepare to move. (If you'd like help, Sketch handles both kinds of Atlassian cloud migration.)
If you're on Data Center and haven't heard about these changes yet, here's what's coming your way, based on Atlassian's published timeline.
If you're planning renewals around these dates, Sketch's Atlassian licensing team can help at no added cost.
If your organization acquired a company with its own Jira Cloud environment, there are options for merging the two. Here I'll focus on cloud-to-cloud migration, which Atlassian renamed Copy product data in 2024. Org merges are a different beast.
Consolidation is often worth it. A national restaurant brand cut tool costs by 20% after consolidating its tool sprawl with Sketch. The checklist below applies to both kinds of migration unless I note otherwise.
First, understand your scope. Instances carry different sizing in users and subscription tiers. Data Center has no subscription tiers, so you need to understand exactly which features each tier gives you and what fits your organization best.
Say one group of users needs its own Jira instance to work independently from everyone else. You'd have to go Enterprise. Free, Standard, and Premium include one instance, while Enterprise allows up to 150.
Cloud list prices went up on October 13, 2026, so read Atlassian's fall 2026 pricing changes before you budget. If you're moving Jira and Confluence together, price out the Teamwork Collection too.
Every test migration into your production instance will bring users into it. If you migrate into production (or even your sandbox instance tied to your production instance) instead of a separate site, you'll automatically bring those users over, and that affects your users and your groups.
The big call-out: know how many users will land in your target cloud instance, so you don't exceed your expected billing model, and build that into your subscription. When you approve group permissions, any active users in your cloud site are added to your bill. A cloud migration trial lasts the duration of your Data Center subscription and keeps test runs out of production.
To migrate from Data Center, you'll have to manage any users without valid emails or with duplicated ones. Data Center had no email requirement. In multiple migrations, I've found several users tied to a single email, or invalid addresses added just to fill a field. In cloud, everything is driven off your email address, so these must be fixed before you can migrate.
The migration assistant gives you some options, but I recommend a deeper dive into those users. Maybe you don't need some of them at all. Maybe they need a new email address. Duplicated emails need to be deleted, or those users separated out with their proper email address.
The tooling follows set logic for groups, which can lead to intended or unintended consequences. Groups with the same name in your source and destination will merge, and those users may gain or lose permissions based on the expected use of that group.
Before migrating, check for those conflicts. Do you need to change names? Maybe it's all by design and works out perfectly. Either way, know which groups match and how that might affect your teams once they hit cloud.
The admins performing the migration need specific permissions. On Data Center, you need system admin access. On cloud, you will need org admin access. Without these permissions on both sites, the user performing the migration will not be able to run it.
Public access settings exist in both Data Center and cloud, for Jira and Confluence. Filters, global and space level permissions – for both Jira and Confluence, all have controls to allow for public access. The tooling calls them out during migration, but careful review is recommended for all public access before moving to cloud.
Even when a filter is open to anybody, certain instance permissions keep it from being widely available on the web. Regardless, we recommend turning off public access settings and focusing on group permissions to give users access. Confluence gets more nuanced, which makes it worth looking at individually.
Add-ons require time and attention. Start by understanding which add-ons you have today and which you'll need in cloud. Maybe an add-on provided value in Data Center, but cloud now handles it natively. That's an opportunity to reduce your add-ons.
I still recommend having your add-ons installed in your cloud instance when you migrate. That helps preserve your add-on data. Then you can work on a deprecation plan as time moves on.
Moving to cloud is a good introspective moment. You'll often find small groups of teams using specific add-ons that may not be worth the price. Keep in mind that when you pay for an add-on, you pay for every user on the product it extends. If one team out of hundreds, or even thousands, uses an add-on, it may not make sense to keep it.
Two common examples: workflow add-ons gave Data Center more granular control over validators, conditions, and post functions, and a lot of that is built into Jira Cloud natively. In Confluence, many teams are very attached to Miro, a great whiteboarding tool, while Confluence Cloud has whiteboards built in. Native Jira automation also covers more ground than many teams expect.
In cloud, teams are handled at the organization level. Shared teams in Advanced Roadmaps on Data Center get converted to Atlassian Teams. When you migrate into production, teams will get duplicated through the migration path currently available, so you may land in cloud with multiple copies.
There are recommendations for mitigating this during migration. Cloud to cloud, you likely won't run into it, but teams with the same name may cause conflicts to address before migrating.
This one is specific to Jira. Confluence doesn't have the same concerns. Whether you're coming from Data Center or another cloud site, you'll run into duplicate configurations. That's why we try to minimize the number of migrations between sites.
Workflow schemes, field schemes, custom fields, statuses, priorities: any configuration item can be duplicated. Atlassian follows set logic to merge them. If an item doesn't meet that criteria, the tooling creates a duplicate to preserve your data, with "(migrated)" next to its name. Teams often notice this on their first look at the new cloud environment, and sometimes that's enough to throw them off their work.
Depending on your migration, this may be unavoidable. Try to get it in in one shot as much as possible. If you migrate in succession, you may be able to avoid duplicates. The real issue comes when configurations get modified between migrations. That's when you see a cascade of varying configurations.
This isn't common, but cloud caps the number of characters in certain fields, and Data Center doesn't. Atlassian documents the limits, along with queries you can run to find fields that exceed them, so you can fix them before migrating. Cloud to cloud, you'd have to worry about this less.
Integrations may not work the same way in cloud as they did in Data Center. Understand the critically used ones and test their integration abilities in cloud. APIs will change too, so plan to send prep communications about those changes as part of your change management plan leading up to the migration. This way users relying on those can repoint their API calls to avoid downtime.
Guard lets you control how your users get access, among many other features. If you want single sign-on (SSO), you need Guard.
On Data Center, you may be used to LDAP or Active Directory. In cloud, Guard replaces that. There are ways to sync various Active Directory instances with Guard, and that's worth exploring before you move.
If you're still on Data Center, prep your instance before moving to cloud:
That covers the high-level topics to consider before moving to cloud. Atlassian's own Jira pre-migration checklist runs 24 items, 11 of them mandatory.
March 28, 2029. That day, Data Center subscriptions and their Marketplace apps expire and become read-only. Bitbucket, Bamboo, and Jira Align Data Center are excluded.
Yes. Existing customers can renew the users and apps they have today until March 28, 2029, with renewals prorated to that date. New subscriptions, Marketplace apps, and expansions end for existing customers on March 30, 2028.
Yes. Free, Standard, and Premium plans include one instance of each Atlassian app. An Enterprise plan allows up to 150 instances within the same plan.
Yes. Single sign-on in Atlassian Cloud requires Atlassian Guard. For teams leaving Data Center, Guard replaces LDAP or Active Directory for controlling user access.
When a configuration item can't merge with one in the destination site, the migration tooling creates a duplicate to preserve your data and adds "(migrated)" to its name. Fewer migration passes mean fewer duplicates.
Whether you're moving from Data Center to cloud or merging cloud sites after an acquisition, Sketch can help you plan and run the migration. As an Atlassian Solution Partner, we also handle licensing and renewals. Our rates are never higher than Atlassian's direct pricing, and the licensing review is free. After go-live, Atlassian training helps your teams settle into cloud.
Ready to get started? Let’s plan your migration together. The first few hours of consulting are always free. After that, we’ll give you as much or as little support as you want.