Before you commit to Jira Cloud: What Data Center customers should validate

Jira Data Center customers are planning more than a migration. They are being pushed into a platform decision under a deadline. For many teams, Jira Cloud will quickly become the assumed path, sometimes before anyone has checked whether the current estate can move cleanly. Years of apps, scripts, automations, identity rules, integrations, reports, and compliance requirements do not disappear because the destination seems administratively convenient.

This guide helps enterprise teams slow the decision down before the rebuild speeds up. The bigger question is what operating model replaces Data Center after the migration. Use this guide to compare the paths, check the assumptions behind Jira Cloud, and decide whether Cloud, a phased move, or a self-hosted or air-gapped option is the right direction before commitment.

What is actually changing for Jira Data Center customers?

Atlassian’s final end-of-life date for affected Data Center products is March 28, 2029. The planning pressure starts earlier because purchasing, license expansion, Marketplace app availability, and support all change before or at that date.

The confirmed timeline

• December 16, 2025: Atlassian stopped accepting new Data Center Marketplace app submissions. Existing Data Center customers can still buy Data Center Marketplace apps until March 30, 2028, subject to Marketplace Partner availability.
• March 30, 2026: New customers can no longer buy new Data Center subscriptions or new Marketplace Data Center apps.
• March 30, 2028: Existing customers can no longer buy new Data Center subscriptions, new Data Center Marketplace apps, or subscription expansions.
• March 28, 2029: Affected Data Center subscriptions and Marketplace app licenses expire. After that, teams can access existing data, but they cannot add new data or perform new actions.

Atlassian says it will continue technical support, critical security bug fixes, and connectors from Data Center products to Atlassian Cloud through March 28, 2029.

What sits outside the main timeline

• Bitbucket Data Center: Bitbucket Data Center is not included in the Data Center end-of-life announcement. Atlassian says existing Bitbucket Data Center customers will get access to a Bitbucket Hybrid License that allows them to run both Bitbucket Data Center and Bitbucket Cloud.
• Jira Align Data Center: Jira Align Data Center is also not included in the main Data Center end-of-life announcement. Self-hosted Jira Align follows a separate support policy: Atlassian supports the current release and the one before it.
• Extended maintenance: Atlassian says extended maintenance may be available by exception after March 2029 for certain Data Center customers. Do not build the migration plan around it unless Atlassian confirms it for your organization.

What this means for enterprise buyers

The timeline gives existing customers time to plan, but it limits how long they can keep expanding the current setup. Renewal timing, license expansion, Marketplace app availability, and Cloud-readiness work all need attention before the final deadline.

The most practical next step is app inventory. For each critical Marketplace app, check current support, renewal path, Cloud availability, migration path, feature differences, security review needs, and whether the app should move, be replaced, or be retired.

The clock on this decision runs out before 2029

March 2029 is the final deadline, which makes it far too late as a planning start. Before cutover, teams still need discovery, security review, procurement, test migrations, user testing, change planning, and stabilization. These steps depend on each other, so delays early in the process reduce the time left for execution.

What the runway needs to include

A realistic migration plan should account for:

• Current-state discovery and dependency mapping
• Destination assessment and gap analysis
• Security, legal, and compliance review
• Procurement and renewal planning
• Test migrations and results analysis
• User acceptance testing
• Change-freeze scheduling
• Production cutover
• Post-migration stabilization

For a clean Jira estate, this may be manageable within months. For a complex environment with script-heavy workflows, critical Marketplace apps, complex identity rules, integrated systems, or regulated data-handling requirements, teams should plan for a longer runway.

The larger the estate, the less useful the 2029 date becomes as the only planning anchor. The real question is how much time remains after discovery, approvals, testing, change planning, and stabilization are added to the plan.

What gets harder closer to the deadline

A later start leaves less room to change scope, retire apps, compare another path, or work through commercial decisions before the final cutoff. Renewals, migration offers, dual-running costs, app licensing changes, and parallel evaluations all affect the final budget. Work through them while there is still room to adjust the plan.

Where assisted Cloud migration fits

FastShift is relevant once Atlassian Cloud has already been chosen. Atlassian describes it as a program for eligible customers moving to Cloud on a 2- to 6-month timeline, with senior sponsorship and a commercial Cloud license for 1,000+ seats.

The key point for this guide is simple: assisted migration can help with the move to Cloud. The destination decision still needs to happen before that work begins.

What risks appear when teams treat Jira Cloud as the automatic next step?

Atlassian is moving Data Center customers toward Cloud, so Jira Cloud will appear in almost every serious migration plan. The risk begins when that path becomes settled before the team has checked what has to move, what has to change, and what might break the plan.

Once Cloud-specific work starts, momentum builds quickly. Workflow redesign, identity setup, app decisions, integration changes, and budget planning all make it harder to compare another path on equal terms. That comparison is worth running before those choices are made.

Assumptions to check early

The capacity problem

Jira migration work often lands on the same teams keeping the current estate running. Discovery, migration testing, stakeholder management, and cutover preparation all require focused time. When that work competes with day-to-day platform responsibilities, decisions slip even when the plan looks ready. For a migration of this size, assign owners early. Apps, identity, workflows, integrations, security review, finance, and cutover planning all need someone accountable.

What migration paths should buyers compare before committing?

Choosing a destination and choosing a migration approach are separate calls. A team may choose Jira Cloud and still need to decide whether to move directly, phase the migration, clean up the estate first, or use an assisted path. Another team may find that Cloud needs to be compared with a self-hosted or air-gapped option before any rebuild work begins.

For teams that need to include a self-hosted or air-gapped path, Plane belongs in that comparison. The section below sets out how it compares against Jira Data Center and Jira Cloud on deployment, identity, app dependency, import path, and cost.

What should buyers check before choosing Jira Cloud?

Jira Cloud will be in the evaluation for most Data Center customers because Atlassian is shifting its focus to Cloud, and Data Center reaches end of life on March 28, 2029. Before committing, teams need to check whether the chosen Cloud path fits the estate they actually run: apps, workflows, automations, identity, integrations, security requirements, operating model, and cost.

The checks below keep the decision grounded in how the environment works today, not how simple it looks in a migration plan.

1. Existing Atlassian dependencies

Start by naming what has to carry forward from the current Atlassian setup. Some teams may need continuity in user training, integrations, reporting, support relationships, or procurement terms. Write those reasons down, then separate genuine requirements from habit.

2. Marketplace apps and app data

For every critical Marketplace app, check the Cloud version against actual usage. Look at Cloud availability, feature gaps, app-data migration, billing model, security review, and whether the app should move, be replaced, or be retired.

JCMA can assess Marketplace apps and migrate app data only when the app has a migration path provided by its Marketplace Partner. Surface app gaps before commitment, while they can still change the destination decision.

3. Workflows and automation

Treat workflow structure and workflow behavior as separate checks. A workflow can appear in the target environment and still behave differently where properties, triggers, conditions, post-functions, or app logic are involved. Test core workflows in a sandbox before the destination is treated as settled.

Automation rules need the same treatment. Check actors, audit logs, global settings, cross-project dependencies, external triggers, and rules that carry business-critical process logic. Use outcome tests rather than object counts.

4. Identity and access

Moving from Data Center identity patterns to Atlassian Cloud’s organization-level administration model changes how users, groups, product access, and permissions are managed. Before migration planning moves ahead, map managed accounts, domain verification, unique email requirements, group conflicts, nested groups, SCIM sequencing, product access, and permission risks.

For commercial Atlassian Cloud, SAML SSO and SCIM provisioning commonly bring Atlassian Guard Standard and an identity provider into scope. Government Cloud and Isolated Cloud package identity and security controls differently, so model the cost and setup by deployment option rather than using one Cloud assumption.

5. Security, residency, and deployment model

Review the selected plan or deployment model in detail. Data residency, audit logs, support access, Marketplace apps, subprocessors, service levels, and shared-responsibility requirements can vary by product, app, plan, and deployment model.

For Government Cloud or Isolated Cloud, check current product availability, app availability, migration support, identity controls, data residency, and authorization status. Jurisdiction-specific requirements need legal review against the selected deployment model rather than a broad Cloud label.

6. Cost and operating model

Build the cost model before Cloud becomes the chosen path. Include the selected plan, identity and security controls, Marketplace app licensing, migration labor, parallel operation, support, training, and change management.

Then look at the operating model. Can the organization manage users, apps, workflows, integrations, reporting, governance, and procurement in this model after Data Center? If the answer is unclear, the decision is not ready.

When should self-hosted or air-gapped alternatives enter the evaluation?

Jira Cloud will appear in most Data Center migration plans because Atlassian is ending affected Data Center products and shifting focus to Cloud. Before Cloud-specific rebuild work begins, teams that need deployment control should compare a self-managed path in the same decision cycle.

This path is worth adding when one or more of these conditions apply:

• The project-management system needs to run on customer-controlled infrastructure.
• Network isolation, internal-only access, or air-gapped operation is part of the security requirement.
• Legal, security, or procurement teams need a deployment model outside the usual SaaS review path.
• Developer-tool integrations, identity architecture, or data-boundary rules are easier to manage in a self-managed environment.
• The team wants to reduce long-term dependency on Marketplace-heavy workflows or fragmented tooling.

The table below compares the three options on the areas that usually decide the outcome. Read it as a starting point for the evaluation, not as a substitute for testing against your own estate.

When tooling consolidation is part of the decision

For many teams, the self-hosted question is only one part of the evaluation. The more common issue is app sprawl.

Over time, Jira estates often collect Marketplace apps for work intake, approvals, reporting, documentation, service workflows, automation, dashboards, and small workflow gaps. Each app adds something useful, but it also adds cost and review work during renewal, security approval, and migration planning.

This matters more under the Data Center deadline because every critical app needs a decision:

• Can it move to Cloud?
• Does the Cloud version cover the actual use case?
• Is there a Marketplace Partner migration path for app data?
• Does the app introduce new security or subprocessor review?
• Should the workflow move, be rebuilt, replaced, or retired?

When a Marketplace Partner has no Cloud migration path, the decision cannot wait until cutover planning. The team has to decide whether to keep waiting, rebuild the workflow, replace the app, or remove that dependency from the future setup.

This is where platform comparison becomes useful. If project work, documentation, and request intake can live closer together, fewer app-backed workflows may need to move at all. Plane includes project management, a wiki, and customer request intake in one product, so teams can test which Jira-side app dependencies need to be carried forward, which can be simplified, and which can be removed before the next operating model is chosen.

Where Plane fits

Plane belongs in this comparison when the team wants to test a self-managed operating model, rather than carry the Jira estate forward feature by feature.

Use the proof of concept to check four things:

• Import path: Plane has separate Jira Cloud and Jira Server importers. The Jira Cloud importer brings over issues, users, labels, priorities, comments, workflows, and field mapping. The Jira Server importer brings over issues, states, priorities, users, comments, labels, issue types, and parent-child relationships. Jira Marketplace apps, scripts, and custom app behavior do not move into Plane as Jira apps, so those workflows need a separate decision.
• Air-gapped operations: Plane’s Airgapped Edition can be deployed with Docker or Kubernetes. In an air-gapped setup, OAuth flows, API communication, service-to-service traffic, and internal integrations stay inside the isolated network. Teams also need a process for offline licensing and moving images or Helm charts into an internal registry.
• Identity: Plane supports OIDC and SAML SSO on Pro and Business. LDAP requires Plane Commercial Edition with an active Enterprise plan license.
• Commercial model: New self-hosted Commercial purchases have a 10-seat minimum. New Air-gapped purchases have a 100-seat minimum. Existing customers keep their current terms.

For Plane’s perspective on this path, read our open letter to Jira Data Center customers.

How to compare fairly

A self-hosted alternative should be judged against the organization’s future operating model, rather than against Jira Data Center feature by feature. The useful questions are what needs to migrate, what needs to be rebuilt, and what can be simplified before the next platform decision is made.

What should be discovered before choosing any migration path?

Before choosing Jira Cloud, Plane, or any other path, teams need a clear view of what their Jira estate depends on today. The important details often sit outside the obvious inventory of projects and users.

Permissions, apps, workflows, automations, reports, and integrations tend to carry years of operational history. Missing them during discovery can distort the timeline, cost model, and final platform decision.

What discovery needs to cover

• Projects, users, groups, and permissions: who owns each project, which permission schemes are active, and where access changes could create risk.
• Workflows, boards, sprints, custom fields, dashboards, filters, and reports: which configurations are still used, which ones are business-critical, and which ones matter to teams outside the Jira admin team’s direct view.
• Automations, scripts, and external triggers: what process logic exists, who owns it, and what may need to be rebuilt, replaced, or retired.
• Attachments, historical data, and audit records: what needs to move, what needs to be retained, and what records are required for compliance or reporting.
• Integrations: every system that reads from or writes to Jira, including CI/CD pipelines, source control, monitoring tools, ITSM platforms, BI systems, data warehouses, bots, webhooks, and internal scripts.

Handle Marketplace apps as a separate track. For each critical app, document the owner, usage, criticality, Cloud availability, app-data migration path, security implications, and whether the app should move, be replaced, or be retired.

What should discovery produce?

Discovery should leave the team with practical inputs for the decision and the migration plan:

• App rationalization matrix: what moves, what gets replaced, and what gets retired.
• Identity readiness review: what needs to be resolved before user and group migration.
• Workflow and automation complexity map: where scripts, process logic, and business-critical behaviors need testing.
• Integration dependency register: which connected systems need owners, migration plans, and test coverage.
• Security and compliance checklist: what needs review before the destination is approved.
• Migration risk register: which blockers need executive visibility or trade-off decisions.
• Leadership decision memo: the summary that closes the evaluation phase and gives the migration program a clear direction.

Without this discovery work, the team is making a platform decision with an incomplete view of the system it needs to move.

Which technical dependencies can change the migration plan?

A list of projects, users, and apps gives the team a starting point. The real scope often sits in identity setup, app behavior, scripts, integrations, data, and cutover constraints.

Check the areas below before the team commits to a path. Any one of them can change the timeline, cost, risk, or final destination.

1. Identity and access

Identity migration changes how users, groups, product access, and permissions are managed in Cloud. Before planning moves ahead, check:

• Unique email requirements across the instance
• Managed account sequencing and domain verification
• SCIM provisioning order
• Duplicate or conflicting group names
• Nested group handling
• Product access assignment across business units
• Permission risks during migration

For large organizations, these checks need to happen before the migration path is settled. Fixing access issues during production planning leaves too little room for clean decisions.

2. Marketplace apps

Use the app review from the Jira Cloud checklist as the baseline here. The technical planning question is narrower: which apps can change migration scope, timeline, or architecture?

Pay closer attention to apps that control approvals, reporting, SLA tracking, workflow extensions, compliance records, or automation. If an app has no supported Cloud migration path, the team needs a decision before technical planning moves forward: rebuild the workflow, replace the app, retire the dependency, or keep that process outside the migration path.

For Government Cloud or Isolated Cloud, app availability should be checked against the selected deployment model before commitment.

3. Workflows and automation

Check workflow structure and workflow behavior separately. A workflow can move and still behave differently where properties, triggers, conditions, post-functions, or app logic are involved.

For ScriptRunner, Groovy-based logic, or other script-heavy setups, keep a separate migration track. Post-functions, validators, conditions, listeners, scripted fields, and JQL-dependent logic should be inventoried, checked against Cloud alternatives, and tested in the target environment.

Automation rules need the same treatment. Check rule actors, audit logs, global settings, cross-project dependencies, external triggers, and rules that carry business-critical process logic. Test outcomes, not object counts.

4. Integrations and data

Pull in owners for every system that reads from or writes to Jira: CI/CD pipelines, source control, incident management, BI and reporting tools, data warehouses, bots, webhooks, and internal scripts.

Data Center-era linking and custom integration patterns also need review. Some Atlassian product links can be reconfigured through supported Cloud linking paths. Other integrations may need OAuth 2.0 setup or a different architecture.

Also check entity ID changes, attachment handling, historical data completeness, retention obligations, reporting continuity, and audit records across the migration event.

5. Performance and cutover

Cutover planning should come from test results, not estimates alone. Test migrations should show migration duration, downtime windows, storage use, network constraints, and the time needed for post-migration checks.

Plan change freezes, support coverage, test windows, and rollback criteria around those results. The aim is to know whether the migration can be completed and stabilized within the organization’s actual operating limits.

What financial model should be built before presenting to leadership?

Leadership should see the full cost picture before the organization commits to a migration path. Base subscription pricing is only one part of the model. The larger number often sits across identity controls, Marketplace apps, migration labor, parallel operation, training, support, and the operating model that comes after cutover.

Compare every active path on the same basis. If Jira Cloud, a phased Cloud move, or a self-hosted option is under evaluation, each one needs its own cost view.

A useful financial model gives leadership more than a number. It shows what the organization is paying for, which assumptions still need checking, and where cost changes if apps are retired, timelines shift, or another path stays in the evaluation.

What approval questions must security, legal, finance, and IT answer before commitment?

Platform engineering can lead the migration work, but it cannot approve the path alone. Security, legal, finance, procurement, and IT all need to review the plan before execution starts because each team sees a different risk: controls, contracts, cost, staffing, support, and cutover readiness.

Cloud approval, alternative-platform approval, and migration-program approval may use the same discovery work, but they answer different questions. Bring these teams in before the plan has already started to harden.

Security and compliance

Before commitment, security teams should check:

• Which Cloud plan or deployment model covers identity, audit, residency, support, SLA, and compliance needs.
• Which controls depend on Atlassian Guard, Enterprise plan features, Government Cloud, Isolated Cloud, self-hosted deployment, or air-gapped operation.
• Which data is covered by residency commitments, and which support, operational, app, or transient data flows need separate review.
• Which Marketplace apps add vendors, subprocessors, permissions, or data access.
• Which integrations need their own security review.

Legal and risk

Legal and risk teams should review:

• Whether the selected deployment model addresses data sovereignty, regulatory, contractual, and customer commitments.
• Whether the required FedRAMP authorization level is available for the Atlassian products in scope, if the organization needs it.
• Whether jurisdiction-specific requirements are covered by the selected deployment model, support model, subprocessors, and contract terms.
• Which existing contracts, retention obligations, audit obligations, or customer commitments could affect the migration timeline.

Finance and procurement

Finance and procurement should model:

• The full cost of the migration program and the steady-state operating model.
• Which Marketplace apps move, change billing model, consolidate, or retire.
• Dual-running, migration labor, partner support, infrastructure, training, support coverage, and any extended maintenance arrangement.
• How the 2026, 2028, and 2029 milestones affect renewal timing, purchasing flexibility, and commercial planning.
• Whether any alternative path under evaluation has the same cost detail as the Cloud path.

IT and platform engineering

IT and platform teams should define:

• Migration scope and resourcing needs.
• Workstream owners and external support needs.
• Test results required before production cutover.
• Go/no-go criteria and who can make that call.
• Rollback, stabilization, and post-migration support.

If a self-hosted or air-gapped path changes the security architecture, infrastructure ownership, procurement model, or compliance review, include those differences in the same approval process before the organization commits.

How should the enterprise execute once a direction is chosen?

Once the path is chosen and discovery is complete, the migration needs clear ownership across phases. Large Jira migrations involve platform teams, security, legal, finance, procurement, business owners, app vendors, and end users, so execution needs a shared plan that can handle issues found during testing.

The six phases of a migration program

1. Assess. Close the evaluation phase, complete the current-state inventory, assign owners for each major area, and build the risk register before technical execution begins.
2. Plan. Define migration scope, timeline, runbook, procurement actions, security review schedule, support model, communication plan, and the checks required before each phase moves forward.
3. Prepare. Clean data, resolve identity issues, rationalize apps, prepare integrations, configure the target environment, and build test environments that reflect production as closely as possible.
4. Test. Run test migrations and check data integrity, permissions, workflows, automations, reports, integrations, performance, and downtime assumptions. Test expected business behavior, not only whether objects appear in the target environment.
5. Migrate. Run production cutover with a defined change freeze, named go/no-go owner, user communication, support coverage, and a signed-off cutover checklist.
6. Stabilize. Keep a defined support window after cutover. Use it to handle user issues, review access, fix workflow gaps, monitor automations, check reporting, complete training, and apply governance before the old environment is retired.

Risks to handle before production cutover

Each risk needs an owner and a clear mitigation plan before go-live:

• Permission changes caused by group structures, SCIM behavior, nested group flattening, or phased migration drift.
• Apps that move technically but behave differently in production.
• Automations that carry business logic and need scenario-based testing.
• Reports and dashboards that executives rely on.
• Integrations outside Jira admin visibility.
• Rollback plans that depend on backups but have never been tested.
• Stabilization work that is left unfunded or unstaffed after cutover.

Rollback needs a real plan

A rollback plan should define who can call it, which system is authoritative during the transition, how post-cutover data changes will be handled, when users are locked out of the source system, when integrations are frozen, what test results trigger rollback review, and who signs off on the decision.

For most production migrations, rollback depends on a current source backup and a tested restore process. Define that process before the migration runs.

How should leaders make the final migration decision?

The destination decision shapes the operating model, technical roadmap, and commercial path that follows the migration. Leadership should make that call after the team has completed discovery, checked the major risks, and understood what each path requires.

What leadership should have before committing

Before choosing a path, the team should have:

• Completed current-state discovery and dependency mapping.
• A gap registry with effort estimates and risk levels.
• A full cost model covering subscriptions, app licensing, identity and security controls, migration labor, parallel operation, training, and change management.
• A comparison of Jira Cloud and at least one serious alternative where the organization’s requirements make that relevant.
• Security, legal, and compliance requirements reviewed before the destination is finalized.
• A realistic timeline with dependencies, resourcing assumptions, and phase gates.

A fast decision may still be necessary. It should also be clear what has been checked, what remains unresolved, and who owns the risk.

Questions for the leadership discussion

• What operating model is the organization choosing after Data Center: managed Cloud, phased Cloud migration, self-managed infrastructure, or an air-gapped setup?
• What should the next platform make easier than the current Jira estate: app dependency, workflow governance, reporting, identity management, procurement, support, or administration?
• What must carry forward: data fidelity, workflow logic, permission structure, audit records, integration continuity, reporting accuracy, or user experience?
• What should be redesigned before the next platform is chosen?
• Which requirement cannot move, and has the selected destination shown it can meet that requirement?
• What still needs to be checked before the decision is final?

What the decision can look like

A good evaluation may lead to different outcomes. Leadership may decide to:

• Proceed with a direct Jira Cloud migration.
• Proceed with a phased Jira Cloud migration.
• Use an eligible Atlassian-assisted Cloud migration path, such as FastShift, once Cloud is chosen.
• Clean up and rationalize the estate before migration.
• Run a parallel alternative-platform evaluation with clear criteria and a decision date.
• Pilot a self-hosted platform, such as Plane, for specific teams or requirements before making a wider call.
• Delay with a risk plan, review date, and named executive owner.

Bottom line

The Jira Data Center deadline is fixed, and the pressure around it will only get louder. That pressure can make Jira Cloud feel like the decision before the current estate has been fully checked.

A better decision starts with the system as it exists today: apps, workflows, automations, identity, integrations, security reviews, cost, and the work needed after cutover. If Jira Cloud is the right path, those checks make the commitment cleaner. If deployment control, air-gapped operation, or self-hosting is part of the requirement, that path deserves a serious review before Cloud-specific rebuild work begins.

Evaluating a self-hosted or air-gapped path out of Jira Data Center? Talk to our sales team. We can help you review your current Jira setup, understand what would need to move or be rebuilt, and decide whether Plane is the right path for your post-Data Center operating model.