When Atlassian announced the end of Jira Server, it felt like the end of an era.
When they followed up by putting an expiration date on Jira Data Center as well, it stopped being “just another product decision” and became something else: a clear statement that self‑hosting was no longer part of their future.

I run Plane, a core work management tool that teams, sometimes a little too loudly 😅, call a “Jira killer.” We offer both cloud and self‑hosted options. Every time Atlassian changes its roadmap, my inbox fills with the same questions.

• Why are they doing this?
• Are we really all supposed to move to the cloud?
• What happens to teams that can’t?
• Is self‑hosting actually doomed… or just hard?

This post is my attempt, as a founder, to answer those questions honestly and to offer why we’re betting against the idea that the future is 100% SaaS for everyone, everywhere.

1. How we got here

Atlassian’s slow break-up with self‑hosting

If you zoom out, Atlassian’s move is not sudden; it’s the culmination of a decade‑long shift.

1. First, they killed the Server.
   The end of Server licensing was framed as simplification: too many editions (Server, Data Center, Cloud), too much complexity, and a desire to focus all innovation in the cloud. Customers were pushed to either:
• move to Atlassian Cloud, or
• upgrade to Data Center as the “enterprise‑grade” self‑hosted option.
  
2. Then, they starved the Data Center of love.
   For years, most of the shiny new features—AI capabilities, major scalability improvements, integrated analytics, and advanced security/compliance—rolled out to Cloud first (and sometimes only). Data Center kept getting security patches and incremental improvements, but if you were paying attention, it was obvious which child was the favorite.
   
   
3. Now, they’ve put an end date on Data Center as well.
   With the Ascend program, Atlassian has effectively said that by the end of this transition, it will be a cloud‑only company. No more Jira that you can run on your own metal. No more “just spin up another node in your cluster.” No more “we’ll stay on‑prem for the next decade.”
   
   

Is this evil? I don’t think so.
It’s rational. Cloud subscriptions are a better business model for a public company than perpetual licenses:

• predictable, compounding revenue
• more pricing leverage over time
• one codebase to build and maintain
• easier to ship AI‑heavy features that depend on centralized data

If you’re Atlassian, the spreadsheet almost certainly says, “We’ll lose some customers, but the ones who stay will pay more, and our margins will be better. Net positive.”
From their perspective, this makes sense.
From your perspective—especially if you care about self‑hosting—the calculus may look very different.

2. Who gets left behind in a cloud-only world?

Let’s be blunt: not everyone can or should move to Atlassian Cloud.
There are whole categories of teams that are now effectively being told: “Either rewrite your rules around data, security, and risk… or find another tool.”
A few examples we see in our own user base include:

Highly regulated industries

Banks, insurance companies, healthcare organizations, biotech firms, critical infrastructure providers, and government agencies. Many of them:

• have strict data residency requirements
• require infrastructure to be operated by themselves or trusted local providers
• answer to regulators who won’t accept “our SaaS vendor promised it’s fine” as an argument

Atlassian is doing serious work on compliance—FedRAMP, regional hosting, upcoming isolated/sovereign cloud offerings. That is all real.

But for some organizations, any third‑party cloud for core work management is a non‑starter. This is especially true for those that run on air-gapped networks. There is no VPN, no tunnel, no “zero‑trust connector.” The internet simply doesn’t exist from that environment’s point of view.

There is no “Atlassian Cloud” in those networks. There never will be.

Companies with deep on‑prem integrations

The longer a Jira instance has been around, the more likely it has grown tentacles:

• homegrown CI/CD systems
• internal build & deploy tooling
• on‑prem identity systems
• proprietary databases and ETL processes
• departmental automations built around direct DB access or server‑side scripts

For these teams, Jira isn’t “just an app.” It’s wiring in the walls.

Moving all of that to Cloud isn’t just a migration project; it’s a rewiring of the entire house. Some integrations can be rebuilt against Atlassian’s cloud APIs or through “connectors” that bridge your network to theirs. Some can’t. And when they cannot, you’re stuck choosing between:

• dropping functionality people rely on daily
• or rebuilding that logic completely around a new tool

Neither option is trivial.

Teams worried about cost and lock‑in

On paper, the cloud looks cheaper: no servers, no infratsructure team, no upgrades.
But once you get to a few thousand users, the math changes. The stories we keep hearing include:

“Data Center was a painful line item, but we controlled the hardware and the growth. Cloud felt fine in year one, and then we w hit with price increases we could not really push back on.”

In a self‑hosted world, you have knobs:

• run it on cheaper hardware
• move regions or providers
• optimize resources to match your usage patterns

In a cloud‑only world, those knobs live with your vendor. Once all your workflows and data live in their platform, “just switch tools” becomes fantasy for a lot of teams.

This is exactly why SaaS companies prefer the cloud.

3. The collateral damage: Admins and Partners

There is another group caught in the blast radius of this decision: the people whose careers and businesses were built around running Atlassian on‑prem.

Jira admins

If you have ever been a Jira admin for a large on‑prem instance, you know the drill:

• capacity planning
• JVM tuning and upgrades
• plugin compatibility challenges
• disaster recovery plans
• all‑hands‑on‑deck release nights

It is a lot. But it is also a real career path. Many admins are incredibly skilled in large‑scale Jira and Confluence operations.
When Atlassian says “We are ending Data Center,” what some people hear is: “Your expertise is now a liability unless you reinvent yourself around our cloud.”
That is difficult, especially when you work in an organization that cannot follow Atlassian to the cloud.

Atlassian Solution Partners and Marketplace vendors

Then there is the ecosystem:

• consulting firms that specialize in large Atlassian deployments
• Marketplace vendors with DC‑only or DC‑heavy products
• boutique shops offering Jira customization and on‑prem tuning

They get one more significant wave of migration work… and then what?

In a cloud‑only world:

• you do not need personnel to install, size, or patch Jira
• a substantial amount of performance and infrastructure work disappears
• Marketplace is constrained by Atlassian’s cloud extension model
• Atlassian itself owns more of the customer relationship

Strategic partners are already hedging. Some are actively helping clients evaluate non‑Atlassian options for self‑hosting, because they know Atlassian Cloud will simply never be viable for part of their portfolio.

We have seen this directly: Atlassian partners reaching out to us at Plane to say, “We need a self‑hosted story that does not end in 2029. Can we add you to our toolkit?”

That’s not a small signal.

4. Self‑hosting was not the problem. Old self-hosted software was.

Let us be honest: running Jira Data Center was not exactly enjoyable.

It was powerful, but it felt like software from a different era:

• heavyweight installation
• complex upgrade paths
• shared storage, load balancers, bespoke networking
• application compatibility roulette every time you changed versions

If that is your mental model of “self‑hosting,” then yes—self‑hosting seems like a dying art, something only large enterprises and masochists should attempt.

But the world has changed.

• Docker and containers are standard.
• Kubernetes and managed K8s make clustering and scaling routine.
• Infrastructure as code and CI/CD can handle deployments and rollbacks.
• Postgres, Redis, object stores, metrics and logging stacks are well‑understood building blocks.

The problem wasn’t self‑hosting. The problem was self‑hosting software that never really modernized.
When we started Plane, we asked ourselves a simple question:

“What would Jira look like if it were designed today—not just in terms of UX, but in terms of deployment, operations, and freedom of choice?”
The answer definitely was not “another monolith that is hard to run anywhere except the vendor’s own cloud.”

5. What we are building at Plane (and why our users call it a Jira killer)

Plane is opinionated software, but our core opinions are simple:

1. You should be able to run your own tools.
   Cloud is great. We offer it. Many teams love it.
   But self‑hosting should not feel like punishment.
   
   That is why we support:
• simple Docker deployments
• Kubernetes and Helm for more advanced setups
• air‑gapped environments (no outbound calls)
2. We designed Plane so you can run it on your laptop, in your data center, or on your cloud—with the same core product.
3. Self‑hosting should feel like using a cloud product… just on your owb infrastructure.
   Running Plane should not require “Jira admin energy.” Our goal is:
• upgrades via container image, not a 27‑step checklist
• sane defaults out of the box
• clear, scriptable install paths
• metrics and logs you can plug into your existing stack
4. Open source is a feature, not a marketing line.
   Our source is open. If you need to audit it, extend it, or fork it, you can.
   That is fundamentally different from trusting a black-box SaaS with all of your work.
5. We respect your exit options.
   The biggest compliment we get is when users say:
   “We picked Plane because it feels like Jira… minus the fear we will be trapped somewhere we cannot leave.”
   We take that seriously. Your data should not be held hostage. If you ever decide to move away from Plane, you should be able to take your data and go.

So yes, our users call us a “Jira killer.”
Not because we’re trying to recreate every single Jira feature, but because we are trying to fix the two things that hurt the most:

• the operator experience (self‑hosting should not suck), and
• the trust model (your vendor should not have unilateral control over where and how your work lives.

6. If you are on Jira Data Center today, here is what I would do

This part is not “use Plane right now.” It is “do not sleepwalk into a corner.”
If I were responsible for a large Jira DC instance today, I would:

1. Get brutally honest about constraints.
• Are you legally allowed to put this data in a third‑party cloud?
• Would your security team accept it, really?
• Are your integrations realistically portable?
2. If the truthful answer is “No” to any of these, assuming “we will just go to Atlassian Cloud eventually” is dangerous.
3. Model the 5‑year cost and risk, not just the 1‑year migration.
• Cloud may be cheaper this year if you ignore migration work.
• But what happens after price increases, user growth, and new add‑ons?
• What is the cost of losing control over your upgrade timing, your region, and your infrastructure choices?
4. Experiment with alternatives while you still have runway.
   Spin up a Plane instance. Spin up two or three other tools.
   Throw a real project at them. Look at:
• how hard they are to run
• how your team feels after a few weeks
• how much customization you really need versus what you thought you needed
5. The worst time to evaluate alternatives is when you are under a deadline and your existing vendor has an end‑of‑life clock ticking.
6. Don’t ignore the hidden Confluence cost
   Most Atlassian customers don’t run “just Jira.” They run Jira plus Confluence. That means two products, two admin surfaces, two permission models, two upgrade paths, and two places where information goes to die.
   Over time, you get Jira issues pointing to Confluence pages nobody can find, spaces that quietly duplicate each other, and “the real spec is in that other space only a few people can access.”
7. Decide, deliberately, what you want to outsource.
   The conversation about cloud versus self‑hosted is often framed as:
   
   “Do you want to manage servers? No? Then go cloud.”
   That is too shallow. The real question is:
   “What parts of your core workflow are you comfortable outsourcing to a company whose roadmap, pricing, and availability you do not control?”
   There are good reasons to answer “a lot of it.”
   There are equally good reasons, for some teams, to answer “not this.”
   Make that choice on purpose, not because your vendor made it for you.

7. Self‑hosting is not a relic. It is a strategic option.

I’m not interested in dunking on Atlassian.
They built products that defined a category. Many of us learned how to ship software in teams that lived in Jira and Confluence. Many of Plane’s users are former Atlassian customers who still respect what those tools enabled.

But we should not confuse Atlassian’s incentives with our own.
For Atlassian, going all‑in on cloud is logical:

• higher margins
• one platform to build on
• stronger lock‑in
• a story the stock market understands

For many companies, especially the ones I have been talking to, the incentives are very different:

• control over where their data lives
• the ability to integrate deeply with internal systems
• the option to run critical tools in environments that will never be connected to the public internet
• bargaining power that comes from being able to move, not just threaten to move

That is why, at Plane, we’re doubling down on self‑hosting—not as a nostalgia play, but as a first‑class feature of modern software.

We will keep building a great cloud product. Some teams will always prefer to let us handle everything, and that is fine. But we will not ask you to bet your entire future on our cloud.

If you want your work management stack to live on your own infrastructure, in your own country, behind your own firewalls, orchestrated by your own DevOps—we want that to be not just possible, but pleasant.

Self‑hosting is not dead.
It’s just moving away from vendors who decided it no longer fit their business.

We are proud to be one of the teams picking it up.

—

If you are sitting on a large Jira Data Center instance and wondering what comes next, you do not have to make a decision today. However, you do have to start exploring. If you want to see what a modern, self-hosted “Jira killer” feels like, spin up Plane and tell us where it breaks. That is literally how we are building this system.