Jira Data Center to Cloud: 10 Checks Before You Migrate

Before moving from Jira Data Center to Jira Cloud, a team in Kazakhstan needs to answer ten questions. Is the company prepared to keep its tracker data abroad? Which region will it end up in? What will the cloud cost over three years? What happens to apps, scripts, permissions and integrations? Will the migration hit limits? How do you roll back? And would it be better to stay on your own server and switch trackers instead? If you have no answer to at least three of these, it is too early to set a migration date.

This article is for IT leaders, Jira administrators and team leads at companies running Data Center. Inside: the deadlines Atlassian has set, ten checks with action steps, a cost estimate for 100 users, and a summary table of “check → how to verify → what to do if it fails” that you can drop straight into your migration plan.

Data Center deadlines: why the decision can’t wait

Atlassian has locked in the timeline. Keep it in front of you when planning budget and team capacity.

Date	What happens
February 15, 2024	End of support for Jira Server
March 30, 2026	Sales of new Data Center licenses end
March 30, 2028	According to Atlassian partners, the last date for renewals and expansions for existing customers
March 28, 2029	End of support for Data Center: license becomes read-only, Marketplace apps stop working

The practical takeaway is simple. A calm migration is possible while your renewal is active and you have time to absorb mistakes. If testing lands in the final year, any problem with apps or permissions turns into an emergency. We covered the scenarios for leaving Data Center in detail in Jira Data Center shuts down in 2029. Here we focus only on what to check before deciding to move to the cloud.

The checks are ordered by risk. First come the data storage questions that can rule out the cloud entirely. Then money. Then the technical side.

Checks 1–2: personal data and storage region

1. Does Jira contain personal data?

A task tracker looks like a technical tool, but it almost always holds personal data. Employee names and work emails. Customer requests with phone numbers. CRM screenshots in attachments. Data exports for debugging. Candidate resumes in HR tasks.

Before the move, the company has to decide whether it is willing to store this data outside Kazakhstan. Some customers and partners ask for data to be stored in the country, and that needs to be factored in as well.

How to verify: export the list of projects, fields and attachment types. Flag the projects that contain customer and employee data. Use this map to decide what can be stored outside Kazakhstan and what has to be removed or anonymized before the move.

2. Which storage region will you get?

Atlassian Cloud offers data residency: product data can be pinned to a region. The list includes the US, EU, Germany, the UK, Switzerland, Australia, Singapore, Japan, India, South Korea and Canada. Kazakhstan is not on it.

Choosing a region determines which country your data sits in, but it does not make it Kazakhstani. If the tracker holds no sensitive data, or it can be cleaned out, pick the region based on latency and partner preferences. If the data needs to be stored in Kazakhstan, the cloud doesn’t work regardless of price or features. Separately, check Atlassian’s documentation to see exactly which data is pinned to the region and on which plan.

Kazakhstan context. Jira Cloud is paid with a corporate card in US dollars, and the vendor does not issue closing documents that meet Kazakhstan accounting standards. Bring your accounting team into the review before the decision, not after the first invoice. Jira has a built-in Russian interface. If some users rely on the Kazakh language pack from Atlassian Marketplace, check separately whether it is available for the cloud. There are Atlassian partners in Kazakhstan, such as Teamlead, a Gold Solution Partner, and you can discuss licensing and migration with them.

Check 3: three-year cost

The cloud should be compared not with your current renewal but with the total cost of ownership over three years. With Data Center, part of the cost is hidden in infrastructure and administrator time. In the cloud it becomes a per-user subscription.

Estimate for 100 users based on Atlassian’s October 2026 price list with annual billing:

Bundle	Per user per month	Per year	Over three years
Jira Standard	$7.91	$9,492	$28,476
Jira Premium	$14.54	$17,448	$52,344
Confluence Standard	$5.42	$6,504	$19,512
Atlassian Guard Standard	$4.20	$5,040	$15,120
Jira Standard + Confluence + Guard	$17.53	$21,036	$63,108
Jira Premium + Confluence + Guard	$24.16	$28,992	$86,976

The calculation is linear. It doesn’t include volume discounts, price increases over three years, or Marketplace apps, which are billed separately in the cloud. Atlassian’s pricing calculator will give you the exact figure.

What goes on the other side of the scale: the cost of renewing Data Center through 2028, the server and database, administrator time, and the one-off cost of the migration itself. In our experience, the migration is what gets underestimated most often: inventory, test runs and training take longer than expected.

Checks 4–6: apps, scripts and permissions

4. Marketplace apps

Build a register of installed apps: who owns each one, which projects use it, when it was last opened. Quite often a noticeable share of apps hasn’t been used in a long time, and they can simply be left behind.

For each remaining app, answer four questions. Does it have a cloud version? Do the features you use match? How much does it cost in the cloud for your number of users? Where does the app vendor store and process data? The last question takes you back to check 1: a cloud app may run on its vendor’s infrastructure rather than Atlassian’s.

5. ScriptRunner and custom extensions

In Data Center, a lot rests on ScriptRunner and in-house plugins: transition validators, calculated fields, bulk operations, nightly reports. The cloud has a different execution model. Scripts that call the server’s internal API or hit the database directly will have to be rewritten or replaced with Jira Automation rules. Custom server plugins cannot be installed in the cloud.

How to verify: export all scripts, group them by purpose, and for each group decide whether to rewrite it, replace it with a rule, or drop it. If you have dozens of scripts, that is a separate project inside the migration.

6. Permission schemes and groups

Over the years, permission schemes, project roles, issue security levels and groups from the corporate directory accumulate exceptions. During migration it is easy to end up with an employee seeing more in the cloud than they did before. Single sign-on and centralized access management in the cloud require Atlassian Guard, which is included in the cost table above.

How to verify: during the trial migration, create several accounts with typical roles and walk through the sensitive projects. Compare what each role sees before and after.

Checks 7–8: integrations and limits

7. Integrations

Data Center usually sits on the internal network, and integrations with it were built as internal ones. Repositories and CI/CD, monitoring, accounting systems, the corporate portal, messenger bots. After the move, the tracker will be outside. Each integration will need either internet access to the internal system or a reverse setup with webhooks and an intermediary service. Both options have to be approved by the information security team.

How to verify: list inbound and outbound integrations with their owner, protocol and data direction. For each one, decide how it will work with the cloud and who is responsible for it.

8. API and attachment limits

The cloud enforces limits on API request rates and attachment sizes. The values depend on the plan and change over time, so check Atlassian’s current documentation rather than third-party articles. On Data Center your integrations may have polled the server every minute without restriction. In the cloud, that kind of report or sync can hit the limit.

How to verify: calculate the total volume of attachments and the largest files, find the integrations that make the most requests, and run them against a test cloud site under a load close to production.

Checks 9–10: rollback plan and the alternative

9. Rollback plan

A rollback plan is written before the migration, not during an incident. It should include:

1. A trial migration on a copy of the data, and its results.
2. Acceptance criteria: what is checked and who signs off.
3. A change freeze period in Data Center before cutover.
4. A decision on what to do with issues created in the cloud during the pilot.
5. A point of no return: the date after which Data Center switches to read-only.
6. The person responsible for making the rollback call.

The longer teams work in the cloud, the more expensive a rollback becomes, because new data has to be moved back. That is why the rollback itself is tested during a trial run.

10. The alternative: self-hosted on a server in Kazakhstan

If check 1 or 3 fails, the honest question is whether you need Jira specifically. A self-hosted task tracker on a server at a Kazakhstan hosting provider or in your own data center keeps data in Kazakhstan and is paid in tenge under a contract.

One option is Plane. The Community Edition is licensed under AGPL-3.0 and is free with no user limit. The paid self-hosted Commercial and Airgapped editions add SSO, LDAP and granular access permissions, and feature-wise self-hosted is on par with the cloud. The built-in importer from Jira Server and Data Center moves projects, issues, comments, attachments, statuses, links, sprints and users. Automations, dashboards, JQL filters, ScriptRunner scripts and permission schemes don’t carry over, but as checks 5 and 6 show, they would have to be rebuilt for a cloud move too. We described the process in Jira to Plane migration.

Summary table: check → how to verify → what to do if it fails

#	Check	How to verify	What to do if it fails
1	Personal data	Map of projects and attachments, decision on storage location	Anonymize data or choose self-hosted in Kazakhstan
2	Storage region	Compare the region list with company and partner requirements	Rule out the cloud
3	Three-year cost	Price-list estimate plus apps and migration	Trim subscriptions or compare with self-hosted
4	Marketplace apps	Register, cloud versions, prices, data storage location	Find a replacement, drop the app or postpone the move
5	ScriptRunner and plugins	Export scripts, group by purpose	Rewrite, replace with rules, budget the time
6	Permission schemes	Test accounts by role	Simplify schemes before migrating
7	Integrations	Register with owners and data direction	Rebuild on webhooks, get security sign-off
8	API and attachment limits	Load test on a test site	Switch polling to events, lighten reports
9	Rollback plan	Trial migration and trial rollback	Don’t cut over until rollback is verified
10	Self-hosted alternative	Compare cost and requirements with the cloud	Pilot an alternative tracker with one team

If checks 1–2 fail, you can stop there: the cloud scenario is off the table. Failures in 3–8 mean extra work and budget. Without item 9, you should not cut over under any circumstances.

How we do it

We start with a diagnostic of the installation: an inventory of projects, apps, scripts, permissions and integrations, plus conversations with accounting and the information security team. The client gets answers to all ten checks and a comparison of two scenarios: Atlassian Cloud or a self-hosted tracker in Kazakhstan. Then we move one team in pilot mode, verify permissions, integrations and rollback, and only after that scale to the remaining projects.

Details on the process and scope of work are on the Jira and Plane task tracker implementation page.

---

Sources. Data Center timeline: atlassian.com/enterprise/data-center. Jira, Confluence and Guard pricing: Atlassian price list. Data storage regions: Atlassian, data residency. Plane: plane.so/pricing and the GitHub repository. Prices are as of October 2026 with annual billing and may change.

Terms in plain words

Data residency

The ability to choose the country where a cloud service stores your data. The region determines the country of storage, but Kazakhstan is not on Atlassian’s list.

Atlassian Guard

A paid Atlassian add-on for employee single sign-on and centralized access management in the cloud. It is billed separately per user.

Marketplace apps

Third-party add-ons for Jira. Not all of them have a cloud version, and cloud versions may store data with their own developer rather than with Atlassian.

ScriptRunner

A popular Data Center add-on used to write custom validations, calculated fields and reports. In the cloud these scripts are usually rewritten or replaced with Jira Automation rules.

Webhook

An automatic notification one system sends to another when something happens, for example when an issue changes. It lets cloud Jira tell internal systems about events without constant polling.

API limits

An API is how programs exchange data. In the cloud the number of such requests is capped, and frequent reports or syncs can hit that ceiling.

Rollback plan

A predefined procedure for returning to the old system if the move goes wrong. It includes a trial migration, acceptance criteria and a point of no return.

Self-hosted

A tracker running on a server at a Kazakhstan hosting provider or in your own data center. It removes the question of storing data abroad, and hosting is paid in tenge under a contract.