The email from Atlassian has been sitting in someone's inbox for months. Maybe it got forwarded to IT with a 🤔 emoji. Maybe it got triaged to "figure out later."
Well. March 30, 2026 is here. Later is now.
As of today, Atlassian is no longer selling new Jira Data Center subscriptions. Feature development has stopped. The full EOL clock is ticking toward March 2029, and if you're running a large organization on DC, the decision in front of you goes a lot deeper than just "pick a new project tracker."
Because here's the thing most migration guides aren't talking about:
For a huge number of teams, Jira Data Center became your operational data backbone.
The Problem Nobody's Writing About
Google "Jira Data Center alternatives" right now and you'll get a flood of articles comparing Linear, Monday, ClickUp, and Jira Cloud.
Those articles aren't wrong — for teams using Jira to run sprints and track bugs, those are reasonable places to look.
But spend 20 minutes on the Atlassian Community forums and Reddit threads and you'll find a completely different category of panic:
- "We built 12 internal tools on top of Jira's data model. How do we migrate those?"
- "Our compliance workflows live in custom fields and ScriptRunner automations. This isn't a ticket migration, it's a full system rebuild."
- "We're a bank. We cannot move to Atlassian Cloud. Data sovereignty requirements. What do we do?"
These teams aren't looking for a project tracker replacement. They're looking for a data platform — something that holds structured operational data, exposes it via APIs, lets non-technical teams interact with it safely, and runs on their own infrastructure.
That's a completely different problem that most migration guides don't address at all.
How Did Jira Accidentally Become a Data Platform?
It happened gradually - and honestly - because Jira is really good at a few things that have nothing to do with sprint planning:
Flexible data modeling. Custom fields, issue types, and screens let teams model data structures that had nothing to do with software development. Asset registers. Compliance checklists. Procurement workflows. Client intake forms. If you could stuff it into an "issue," someone tried.
Serious access control. Jira's permission schemes are powerful. Enterprises used them to control who could see what, down to a granular level. In regulated industries - finance, healthcare, government — this became load-bearing.
On-premises deployment. For organizations that cannot put their data in someone else's cloud (by law, by policy, or by security mandate), Jira DC was one of very few enterprise tools that ran on your own infrastructure, your own DB, under your own rules.
The marketplace. Plugins like ScriptRunner let engineering teams build automations and custom business logic directly on top of Jira's data layer. Over time, these stopped being plugins and started being core operational systems.
The result: a significant chunk of Jira DC customers have mission-critical workflows built on top of Jira's data model - and migrating them to Jira Cloud or any SaaS ticketing tool isn't really a migration. It's a ground-up rebuild.
The Three Categories of DC Customer
Before you can figure out your path forward, you need to be honest about which box you're actually in.
🏃 Category 1: The Agile Shop
You use Jira DC primarily for sprint planning, backlog management, and bug tracking. Some customization, but your core value is the PM workflow.
Your path: Jira Cloud, Linear, or Monday.com probably work fine. Atlassian's migration tooling is designed for you. But start now - migrations at your scale take 6–12 months.
🏦 Category 2: The Compliance-Constrained Enterprise
Finance, healthcare, government, or another regulated industry. You may want to go to cloud but you literally can't yet. Data residency requirements, FedRAMP needs, air-gapped environments, the whole fun list.
Your path: Complicated. Atlassian has committed to FedRAMP High and IL5 cloud environments before full EOL, but government authorization timelines are out of their hands. You need a contingency plan, and you need it before March 2028 - because that's the last date you can renew DC licenses.
🔧 Category 3: The Operational Platform Builder
You've built internal tools, structured workflows, data repositories, and custom automations on top of Jira's data model. Devs have direct DB access. ScriptRunner logic has become core business infrastructure. Other systems depend on Jira's data via API.
Your path: You don't have a PM tool problem. You have a data platform problem. And this is where the conversation gets interesting.
⚡ Quick Category 3 audit: Custom fields storing business data → other tools reading Jira via API → ScriptRunner doing real business logic → non-dev teams using Jira as a primary data interface → direct DB access to Jira's PostgreSQL. Any of these = you're probably in Category 3.
What Category 3 Teams Actually Need
If you're Category 3, a new project tracker doesn't solve your problem. Here's what you're actually looking for:
- ✅ A structured data layer - store operational data modeled your way, not constrained by the "issues and epics" metaphor
- ✅ Automatic APIs - REST and GraphQL on your data so your existing integrations keep working without custom API development
- ✅ A no-code interface - non-technical teams manage their own data without filing tickets to engineering every time
- ✅ Field-level access control - granular, role-based permissions that your compliance team can actually audit
- ✅ Self-hosted deployment - runs on your infrastructure, your database, your rules. Data never leaves your environment.
- ✅ Extensibility - automations, workflow triggers, and custom logic on top of the platform
Sound familiar? It should. That's what Jira DC was giving you - buried under a ticket tracking metaphor that was never really the point.
What Directus Is (and What It Isn't)
We're going to be blunt here, because trust matters more than a closed deal.
Directus is not a project tracker. If you need sprint boards, velocity charts, and backlog management - stop reading, go look at Linear or Jira Cloud. Though you can structure within Directus We genuinely don't do that, and we won't pretend to.
But if your Jira instance was functioning as a structured data platform - a place where operational data lived, teams collaborated on it, and apps consumed it via APIs - that's exactly what Directus is built for.
Directus is the collaborative backend for applications and data. Connect it to any SQL database (PostgreSQL, MySQL, MS SQL, SQLite - whatever you're already running) and you instantly get:
- REST + GraphQL APIs on all your data - automatically generated, no custom dev needed
- A no-code Data Studio - a visual admin interface where non-technical teams read and write data within your defined guardrails
- Policy-based access control - field-level, role-based permissions with full audit logging
- Flows automation - a built-in workflow engine for the automations you currently have in ScriptRunner
- AI-ready data layer - your structured data accessible to AI agents via a native MCP server with policy-based permission guardrails, if you're heading in that direction
And the thing that's directly relevant for DC migration: Directus runs on your infrastructure. Self-hosted. Your database. No data residency surprises. Fully open-source core.
The Practical Migration Path
For Category 3 teams looking at a Directus migration, here's how this typically unfolds:
Step 1: Audit what you actually have
Separate PM workflows (migrate to Jira Cloud) from operational data (migrate to Directus). These are two different projects with different owners and different timelines. Conflating them is where migrations go sideways.
Step 2: Map your data model
Jira's custom fields and issue types can be translated into a proper SQL schema. Do this thoughtfully. Don't just replicate Jira's quirks in a new system. This is the moment to build something cleaner.
Step 3: Stand up Directus on your existing DB
Here's where Directus does something unusual: it works on top of your existing SQL database. Connect it, and it reads your schema and generates APIs automatically. Export your Jira operational data to a clean SQL schema, connect Directus. You have APIs and admin UI immediately, before writing a line of custom code.
Step 4: Rebuild your automations in Flows
Custom webhook triggers, conditional logic, data transformations, external API calls. Most ScriptRunner workflows can be rebuilt in Directus Flows without writing custom code.
Step 5: Pilot one internal tool first
Pick the smallest internal tool that currently depends on Jira data. Rebuild it on Directus. Prove the concept to your stakeholders before rolling out broadly. Enterprise migrations that try to do everything at once reliably fail.
The best part? Migrations aren't a massive headache anymore. Using the Directus MCP, you can have your entire architecture modeled and your data migrated in a day or two (yes, we truly believe this.) The heavier time sink is the evaluation, procurement, and implementation.
The Timeline Reality
The Jira DC timeline looks generous on paper. March 2029 feels far away. But here's the problem: a serious data platform migration in a regulated environment takes 12–18 months to do properly. Evaluation, procurement, implementation, testing, user training, cutover.
The key dates:
- 📅 March 30, 2026 - No new DC subscriptions. Feature dev stops. (Today)
- 📅 March 30, 2028 - Last date to renew existing DC licenses.
- 📅 March 28, 2029 - Full EOL. DC goes read-only.
If you want to be out before the 2028 renewal (and you should...renewing just buys you one more year of a deprecated system), your evaluation window is now. Starting in late 2026 is cutting it close. Starting in 2027 is crisis mode.
The organizations that handle this well are the ones having these conversations today.
What to Do This Week
- Audit your Jira DC instance. Separate PM workflows from operational data. The answer might surprise you.
- Inventory your data dependencies. What external apps, APIs, or integrations depend on data that currently lives in Jira? These are your migration blockers.
- Figure out which Category you're in. It changes everything about your strategy.
- If you're Category 3: Talk to us. We'll be honest about whether Directus is the right fit for your specific situation - and equally honest if it isn't.
The Jira DC EOL doesn't have to be a disaster. For many teams, it's actually a forcing function to build something better. A real data platform, designed for the job, that developers want to work with and non-technical teams can actually use.
But only if you start now.