Jira Data Center end of life in 2029: migration options and plan

Atlassian has announced a phased end for part of its Data Center portfolio. For Jira Software Data Center and the other products covered by the announcement, the final support date is March 28, 2029. That does not mean every instance must shut down today, but waiting is no longer a neutral decision.

According to Atlassian’s official Data Center end-of-life page, the key dates are:

• March 30, 2026 — new customers can no longer buy new affected Data Center subscriptions or new Data Center Marketplace apps;
• March 30, 2028 — new sales, expansions and upgrades end for existing customers, along with sales of new Data Center Marketplace apps;
• March 28, 2029 — end of life for the covered products; after a subscription expires, the instance becomes read-only.

Bitbucket Data Center follows a different path and is not covered by the same conclusion. Check the exact product and contract instead of applying one timeline to the entire Atlassian portfolio.

First decide what you are actually migrating

“Jira Data Center migration” hides at least three different jobs:

1. Jira Data Center → Jira Cloud — the same vendor and a similar domain model, using Atlassian tooling and compatibility assessment;
2. Jira Data Center → another issue tracker — delivery migration with new workflow mapping;
3. Jira Data Center → a Product OS — a model change, not only a tool change, because tickets connect to goals, discovery evidence and outcomes.

No path is automatically best. The decision depends on what your organization actually uses in Jira, not the number of projects in the sidebar.

Option 1: Jira Cloud with Jira Cloud Migration Assistant

If you want to retain Jira’s operating model, Marketplace ecosystem and administration patterns, Jira Cloud is the natural candidate. Jira Cloud Migration Assistant is Atlassian’s path for assessment, planning and migration execution.

Before deciding, check:

• compatibility and the cloud path for every Marketplace app;
• users, groups, permission schemes and identity;
• attachment size and transfer duration;
• custom workflows, fields and automation;
• data-residency, security and compliance requirements;
• behavior differences between Data Center and Cloud features.

For a complex instance, a test migration is not an optional demo. It is the only way to measure duration, errors and manual correction before production cutover. Atlassian’s pre-migration checklist recommends pre-migration checks and a test before the final run.

Option 2: a controlled move to another product system

If end of life is only the trigger for a broader question — why product strategy, discovery and delivery are administered across several tools — moving to a different model may make more sense than copying existing configuration into Cloud.

WorkThroughLine is not a Jira Data Center → Jira Cloud migration tool. It is an alternative destination. The direct OAuth connection supports Jira Cloud; Data Center uses an original CSV export and preflight before any write.

The CSV path can carry and map core operational data such as:

• Jira key, summary, description and issue type;
• status, priority, assignee, reporter and labels;
• parent/epic structure when present in the export;
• estimates and sprint fields present in CSV;
• source identity needed for safe repeated imports.

This is not a complete copy of a Jira instance. Comments, physical attachments, automation, dashboards, filters, permission schemes and private app data may need another export, an API path or an archive decision. Record those limits before the pilot.

The inventory that prevents surprises

Create one row for every project, app and configuration element:

Item	Active use	Owner	Destination	Verification
Jira project	yes/no		Cloud / new system / archive	active-item count
Marketplace app	yes/no		replacement / export / archive	vendor test
Custom workflow	yes/no		mapping / rebuild	status matrix
Automation rule	yes/no		rebuild / retire	test scenario
Dashboard/filter	yes/no		rebuild / archive	stakeholder sign-off

“Nobody knows what it does, but do not delete it” is not a migration strategy. If something has no owner and no active use, its default destination can be a verifiable read-only archive instead of the new production system.

Pilot and reconciliation

Choose a representative project: an active sprint, a historical sprint, custom status, relationships, comments, an inactive user and at least one piece of app-owned data. The smallest project usually hides the problems a pilot should expose.

After import, do not inspect only a few screens. Compare:

• open work items by project and status;
• epics with children and blocking relationships;
• the active sprint and its dates;
• unmapped assignees and reporters;
• comments and attachments when in scope;
• JPD or app data with a separate path.

Download the Jira-to-WorkThroughLine cutover checklist and use it with the detailed migration checklist.

A timeline that does not wait for 2029

• Now: inventory, owner, destination decision and removal of abandoned configuration.
• Before a production project: technical proof of concept and app assessment.
• At least one complete cycle before cutover: representative pilot, reconciliation and training.
• Cutover: change freeze, final export/import, control totals and a clear source-of-truth announcement.
• After cutover: read-only archive according to retention rules and daily exception review during a short aftercare period.

The most expensive choice is not necessarily Cloud or a new product. It is carrying every piece of historical complexity forward without deciding whether it still serves the team.