The Jira Data Center deadline is 2029. The decision is now.

Atlassian has put an end-date on Jira Data Center. February 2029. Roughly three years from now.

Most teams I talk to hear “2029” and file it. We have time. We’ll deal with it next year. And next year they’ll say it again. That’s the trap. The deadline isn’t the problem — the position you’re in when you hit it is the problem, and that position is decided long before the lights go out.

This post is about why the right time to make the call is now, what your real options look like, and how to think about the next four years if Jira is wired into how your organisation runs.

The shape of the decision

Atlassian’s reasoning is rational. Cloud subscriptions compound better than perpetual licences. One codebase ships AI features faster than three. Server went first, Data Center is going next, and the company that emerges on the other side of 2029 is a cloud-only company. From their seat, the spreadsheet works.

From your seat, the calculus is different. You have three doors:

1. Move to Atlassian Cloud. The path of least resistance — until you discover which of your integrations don’t survive the trip, what your renewal looks like at year three, and how much your data residency story changes when the answer to “where does this live” stops being “in our racks”.
2. Stay on Data Center until 2029. Rational only if you think you can plan a complex migration during the last twelve months of vendor support, while every other Atlassian customer in the world is doing the same thing. Pricing power on the renegotiation does not run in your favour.
3. Leave for something else. The only door where you control the calendar.

The mistake is treating door three like it’s the same urgency as the others. It isn’t. The earlier you walk through it, the more leverage you have — over Atlassian’s renewal terms, over the alternative vendor you pick, over the migration window, and over the people who actually have to do the work.

Who actually can’t move to Atlassian Cloud

For some teams, door one isn’t a door. It’s a wall.

Regulated industries. Banks, insurers, healthcare, biotech, defence, public sector. Some answer to regulators who don’t accept “our SaaS vendor said it’s fine” as an answer. Some run on air-gapped networks where there is no Atlassian Cloud — there will never be an Atlassian Cloud — because the public internet is not a thing in that environment.

Companies with deep on-prem integration. A Jira instance that’s been around for a decade has tentacles. Internal CI, identity systems, build tooling, ETL jobs, departmental scripts that talk to the database directly. Moving Jira to Cloud isn’t a migration. It’s rewiring the building. Some of those tentacles can be rebuilt against cloud APIs. Some can’t. The ones that can’t become functionality you lose.

Teams worried about cost and lock-in. On paper Cloud is cheaper. Past a certain seat count it stops being cheaper, and the knobs that used to be yours — hardware tier, region, scaling, how aggressively you cache — now live with the vendor. Once your workflows and history live in their platform, “we’ll just switch tools” becomes the kind of thing nobody actually says out loud anymore.

If you’re in any of those camps, door one is closed. Door two is a slow-motion version of door three with worse leverage. So door three it is.

The real problem with most Jira alternatives

Here’s the part the migration conversations skip.

Self-hosting wasn’t the problem. Old self-hosted software was the problem. The OSS world has Jira-replacement options — Redmine, OpenProject, plenty of others — and the most common comment under every “alternatives to Jira” thread on the internet right now is some variant of we want to move away from Atlassian but every self-hosted alternative seems to require days of configuration or is missing critical features.

That’s the gap. Plenty of tools are self-hostable. Few of them are self-hostable and modern, and cover the breadth of what Jira plus Confluence plus Zendesk used to cover, and install in an afternoon instead of a quarter.

The other gap is what your team actually wants to do once they’re on the other side. The ops world has shifted under everyone’s feet in the last year. People aren’t just clicking through tickets anymore — they’re sitting in Claude, in Cursor, in a terminal, asking an agent to summarise the queue, draft the status note, find the project that’s about to blow its budget. If your replacement tool can’t be talked to by an agent, you’ve solved a 2024 problem with a 2024 answer, four years late.

What we built Ekso to be

Ekso is one workspace for tasks, tickets, time, and money. Help desk, service desk, projects, docs, time tracking, finance — the things that used to need Jira and Confluence and Zendesk and a timesheet tab nobody updates and a spreadsheet for margin, all in one place.

You can run it three ways: in our managed cloud, in your own public or private cloud, or on-premise. Same product, same updates, same agents. Your data, your tenancy, your call. The on-premise option is not a stripped-down “community edition” — it’s the full product, sitting on hardware you control.

And because the work happens in agents now, Ekso ships an MCP server with 104 tools that lets Claude, Cursor, Claude Code, or anything that speaks the protocol read and act on your operations directly. The same questions you used to ask the analyst on your team — which boards are over budget this quarter, who’s overbooked next month, which clients are losing us money — you ask the agent. It comes back with a real table, not a chatbox guess.

That last part isn’t a bolt-on. It’s the reason the architecture looks the way it does.

What the migration actually looks like

The headline claim — most teams move in a weekend — is only credible if you can see what the work involves. So here it is.

The Ekso CLI ships a migrate branch that pulls projects, issues, comments, worklogs, attachments, links, sprints, fix versions, and components from your Jira tenant into Ekso. Two phases — collect pulls everything into a local SQLite cache, apply writes it into your Ekso tenant. The split matters: a 50,000-issue Jira pull can take an hour, and you do not want a network blip during apply forcing you to re-fetch from the source.

The full happy path is four commands:

# 1. Verify your Atlassian credentials and see which projects you can read.
ekso migrate jira list-projects --tenant acme

# 2. Pull one project's issues, comments, worklogs, and attachments
#    into a local cache. Resumable, parallel, ~200 issues/min.
ekso migrate jira collect --project ACME --tenant acme

# 3. Walk the cache and tell me what would happen — no writes yet.
ekso migrate jira apply \
    --process proc_engineering \
    --tenant acme \
    --dry-run

# 4. Commit. Resumable if interrupted.
ekso migrate jira apply \
    --process proc_engineering \
    --tenant acme

Authoring fidelity is preserved. Every comment is attributed to the original Atlassian user (matched by email, or minted into Ekso with no invite email so your team doesn’t get a flood of welcome mail the day before cutover). Every worklog is attributed to the person who logged it. Every Jira issue type — Bug, Task, Story, Epic — comes through. Sprints become Ekso cycles. Fix Versions become cycles. Components become labels and tags. Custom fields like Story Points map cleanly through a YAML field-map, and any custom field you don’t explicitly map falls through losslessly to a Meta slot — nothing gets dropped.

Useful in practice:

• --dry-run shows the exact create plan — would create 1 container, 47 users, 1247 items, 4083 annotations — before any Ekso write. If your field-map has a problem, dry-run tells you with exit code 2 and apply refuses to proceed.
• --resume picks up where a killed run left off. The CLI keeps a source-id → Ekso-id map in the cache; re-runs skip already-applied rows.
• --no-attachments and --no-comments give you a fast first pass if you want to validate the structural migration before pulling 312 binary files.
• The phases can run on different machines. Collect on a workstation that can reach your Jira instance — including a Data Center instance behind your VPN — copy the SQLite file out, apply from a CI runner with Ekso credentials. That’s the path for teams who can’t expose their DC instance to anything that runs in someone else’s cloud.

The full reference, including identity-resolution strategies, the field-map YAML format, and per-source troubleshooting, lives at ekso.dev/cli/migrate/jira. The same migrate branch covers Linear, Azure DevOps, Zendesk, and Countersoft Gemini if you’re moving more than just Jira — see ekso.dev/cli/migrate/overview.

What does NOT migrate

A migration tool that promises to move everything is lying. Here’s the honest list:

• Workflow definitions and transition rules — the migrator snapshots the current status of each issue. Your transitions get re-authored on the Ekso side, which is faster than it sounds because Ekso’s workflow editor is dropdowns, not XML.
• Jira Automation rules — re-author as Ekso rules.
• Permission schemes and project roles — configure access on the Ekso side, post-migration. Most teams discover their old Jira ACLs were 80% dead weight anyway.
• JQL filters and dashboards — re-author. The good news: half of yours probably reference fields nobody updates anymore.

The full per-source gap list is in the docs.

What you should actually do this quarter

Not in 2028. This quarter.

1. Inventory the wiring. List every integration, every plugin, every script that touches your Jira instance. Half of it nobody remembers writing. The other half is load-bearing. You need the list before you can price any move.
2. Get the renewal terms in writing. Ask Atlassian for the path-and-price for each of the three doors. Cloud migration timeline. DC renewal terms through 2029. End-of-life support after. Putting all three on paper turns the abstract decision into a concrete one.
3. Pilot one alternative on one team. Not the whole company. Not the most important board. One team, one project, one quarter. The point is to see what the migration actually costs in friction — not what the deck says.
4. Decide by the end of 2026. Not the project. The decision. Three years of runway is generous if you start now. It’s a panic if you start in 2028.

If the pilot points at Ekso, you’ll know inside a weekend. If it points elsewhere, you’ve still bought yourself the most valuable thing in any vendor-exit conversation: time, leverage, and a real answer to the question “what’s our plan?“

2029 sounds far away

It isn’t. The vendors who’ll be left standing in 2029 are the ones being chosen in 2026. The teams who’ll have moved cleanly are the ones who decided early enough to take the slow lane through it. And the teams who’ll be writing cheques to Atlassian’s professional services arm in 2028 are the ones who, today, in May 2026, are telling themselves they have time.

You have the time if you use it now. That’s the whole post.

---

Try Ekso: ekso.app/get-started — free, unlimited users, no credit card. Migration guide: ekso.dev/cli/migrate/overview. Browse the 104 MCP tools: ekso.dev/mcp-tools.

If you’re working through a Jira exit and want to talk it through, send a note via the contact link on ekso.app — we read everything.