A disclosure first. I make my living in the Atlassian ecosystem: I administer these tools, teach them, and co-host a show about them. This post takes leaving seriously, which means it has to be allowed to land somewhere bad for Atlassian, and for me. Nobody named below sponsored it.
Three weeks ago, writing about Atlassian’s new automation meter, I said I wasn’t predicting an exodus. I also said Atlassian had “handed a specific and capable group a concrete reason to open the question.” I wasn’t going to let an opportunity for content like that get away from me.
In the r/atlassian thread on the announcement, one commenter at a company of around 3,500 people lays out the sequence this post is built on. They used to run Jira on their own hardware. Atlassian retired that option, so they moved to Cloud because it was the road Atlassian left open. Now Cloud is metering their usage. They’re fair about it, too: running their own servers was never free. But that was a cost they could see, budget, and control.
And that’s before we get to Enterprise customers, who have more reason than most to be upset by the announcement. Many people paid for Enterprise precisely because of the unlimited automation, and I imagine plenty of them feel betrayed by the change in terms. The new limits are large enough for most shops, but they’re still less than what these customers were sold.
Most shops will route around the meter with apps like ScriptRunner or JMWE and get on with life. But some customers are angry that the deal changed, and no app changes it back. That anger is fair. It’s also a bad place to make a platform decision from, because “we’re leaving” is an easy thing to say in a meeting and a very expensive thing to do. So before anyone says it out loud, here’s the question, taken seriously: if a big Atlassian shop walked out, where would it even go, and what would it give up?
I’ve been talking this through with a few people whose judgment I trust, and we keep landing in the same place. You can beat every Atlassian product one at a time. For each one below, there’s an alternative that’s better at that specific job. What you can’t buy anywhere else is that Atlassian’s products sit on one platform, sharing users, permissions, links, and data as first-class citizens. Leaving means giving that up, trading one vendor for five, and paying more for the privilege.
Meet Imaginary Bob from ImagiCorp™
To keep this concrete, meet Imaginary Bob. Bob runs the team that manages the Atlassian tools at ImagiCorp™, a company that makes rainbows and, like Bob, does not exist. It’s a composite with no client or employer behind it. If it sounds familiar, that’s because the situation is common.
ImagiCorp is a 2,000-seat Atlassian Enterprise shop, partway through a Data Center-to-Cloud migration it didn’t ask for. It runs the whole catalog: Confluence, “Just Jira” (my shorthand for Jira Software plus Jira Business), Jira Service Management, Bitbucket, and Jira Product Discovery, plus a couple dozen Marketplace apps. It carries a real compliance load, and it’s a conservative buyer. Bob recommends; a CIO, a CFO, and a risk officer sign, and a vendor nobody in that room has heard of is dead on arrival. That shapes every pick below, so I’ll say it once: the best product only wins if it can get signed.
ImagiCorp has decided to leave all at once, which at this size means an 18-to-30-month program. JPD goes first, Jira and Confluence move together so the Jira macros don’t strand, and JSM is the long pole. (I covered how “all at once” turns into a sequence back in February.)
To be clear, this isn’t a crazy scenario. Data Center reaches end of life on March 28, 2029, and because Data Center is a subscription, everyone still on it will see their instance go read-only that day, Marketplace apps included. Server customers could at least keep running unsupported and accept the security nightmare. Data Center customers don’t get that option, so not migrating is its own decision. Staying on Atlassian means rebuilding your stack on Cloud and Forge, and doing nothing means the work those tools were supporting has to go somewhere. I imagine some organizations are having this exact discussion in boardrooms right now.
One ground rule: this is desk research against vendor documentation and pricing pages, not a 2,000-seat bake-off. And Microsoft is out of scope on purpose. If you’re an M365 shop, your answer already runs through your Microsoft agreement, and that deserves its own post.
Confluence: Notion, With an XWiki Dissent
Start with the part Atlassian won’t enjoy. For most people who write in a wiki, Notion is the better product, with an editor, databases, and search that have been ahead of Confluence’s for years. That’s a massive head start on problems Atlassian is just now dealing with. The Enterprise tier documents SAML, SCIM, and audit logging, there’s nothing to patch, and the CIO has likely already heard of it.
What Notion doesn’t change is the relationship. It’s SaaS, with Atlassian’s incentives and the same ability to redefine what’s included at renewal. Its governance is also lighter than Confluence’s space model at this size, and its importer carries pages and structure but not much else.
The dissent is XWiki, the only open-source wiki I’d put next to Confluence at enterprise scale. Per XWiki’s own documentation, its Confluence migration toolkit carries page history, users, permissions, and attachments, which beats Notion on fidelity by a wide margin, and it’s the only pick here that hands back control. It loses on everything a CIO notices: a Java stack to run, an editor 2,000 people have to learn, and a name nobody in the approval meeting recognizes. If the anger is about control, pick XWiki. If it’s about the bill, pick Notion. For this exercise, ImagiCorp chose Notion.
What you lose: Moving to Notion isn’t a free switch. Your content may come across, but every Marketplace macro, every Jira macro, and your page history stay behind. This is also the one move in the exit where users might like where they land.
Jira Software: GitLab Ultimate, Self-Managed
GitLab puts work items, epics, boards, source code, CI/CD, and security scanning on one platform. Self-managed hands this customer back the deployment model Atlassian took away, and that’s the strongest single argument for leaving anywhere in this post. It has nothing to do with usage-based pricing. GitLab documents SAML, SCIM, and group sync at its paid tiers, though SCIM on a self-managed instance is something to confirm against your version rather than assume.
The costs are real. GitLab is weaker than Jira on workflow configurability and portfolio reporting, somebody has to run the servers again, and it only covers developers. Everyone else in Jira needs a different home, which gets its own section below.
I should say where I’m coming from. Until recently, GitLab was my own choice, and one of the reasons I moved to GitHub bears directly on this post: I still live in Jira Cloud, and GitLab’s self-managed platform wasn’t supported for a lot of what I wanted to build on the Atlassian platform. That doesn’t hurt the pick for Bob. If Jira is leaving with everything else, the integration stops mattering, because GitLab’s own work items take its place. It matters a great deal if you’re only leaving part of the way.
What you lose: This one works, but it’s the one your admins will feel most. You lose JQL and everything built on it, which is nothing to sneeze at. You also lose automation rules, custom field schemes, usable work log history, and more than a decade of Jira expertise on the platform team. The importers move work items, comments, and attachments, and each one mangles something, usually user mapping or links. So it’s probably more accurate to say it “works.”
Bitbucket: The Easy One
If GitLab takes Jira Software, Bitbucket comes along for the ride, and it’s the easiest move in the whole exit. Commit history, branches, and tags are the repository, so they move intact. GitLab ships importers for both Bitbucket Data Center and Bitbucket Cloud that bring pull requests and their comments across. If your developers would rather land on GitHub, GitHub Enterprise Importer handles Bitbucket Server and Data Center, carrying commit history and pull requests with their review comments.
The work is everything around the repository. GitHub’s own documentation is plain about what doesn’t migrate: branch permissions, repository settings, and CI pipelines. Every bitbucket-pipelines.yml has to become a .gitlab-ci.yml or a GitHub Actions workflow, and that sounds like the part where the months go. From my own GitLab-to-GitHub migration, it isn’t. The pipelines could be vibe-coded into the new format fairly consistently, because every vendor’s CI YAML describes the same ideas (steps, variables, caches, artifacts) in slightly different words. Budget for review and a test run per pipeline rather than a rewrite. Secrets, runners, and deploy credentials still have to be set up by hand on the other side.
A footnote about meters: Bitbucket Pipelines has always billed in build minutes, and so do GitLab’s and GitHub’s hosted runners. The escape has been running your own runners, and even that got tested. In December 2025, GitHub announced a charge of $0.002 per minute for self-hosted runners in private repositories, then postponed it two days later after developers pushed back.
What you lose: Less here than anywhere else. With GitLab holding both work items and code, the link between a work item and its branch comes back natively, which is the platform argument working in GitLab’s favor. Hold that thought for later.
Jira Business: The Teams Nobody Planned For
GitLab has no home for marketing, HR, legal, facilities, or finance, the teams that ended up in Jira Business because Jira was already in the building. Splitting “Just Jira” creates a second exit inside the first one.
Asana is built for cross-functional coordination, which is what most Jira Business spaces are doing. It documents SAML and SCIM at the Enterprise tier, it’s friendlier to non-technical users than Jira Business ever was, and it gets approved without a fight. If your business teams track more than they coordinate, Smartsheet is the more conservative pick and a familiar name in regulated industries.
The catch is the invoice. Jira Business seats were cheap inside an Atlassian agreement, and Asana charges real per-seat money for several hundred non-technical users. Price it before anyone promises savings.
The consolidation option: Notion already won the wiki, and Notion databases cover a lot of what Jira Business spaces do. Folding those teams in keeps the vendor count down, which matters more than it sounds by the end of this post. It works for teams using Jira Business as a glorified tracker, and falls over the moment someone needs dependencies or a resource view.
What you lose: You won’t be keeping the schemes, the automation, or the links to engineering work that were the reason these teams were in Jira at all. In exchange, retraining is the lightest of the exit, and possibly a net positive.
Jira Service Management: I Personally Don’t Like This Answer, and It’s Still ServiceNow
Everywhere else in this post, the buyer is the platform team. In ITSM, it’s IT leadership, risk, and audit. CAB records, CMDB accuracy, and SLA evidence all get read by somebody external, and they want a vendor who signs a contract and answers the phone at 2 AM. At this size, that’s ServiceNow, 99 times out of 100.
The open-source options deserve a fair hearing anyway. GLPI covers ticketing, assets, CMDB, SLAs, and a portal out of the box, and iTop is CMDB-first with better asset modeling. Both run real organizations. The one in a hundred where they fit has a smaller agent count, no external audit, and real Linux depth on staff. That isn’t this customer. “We self-host our change management system” is a sentence that ends a procurement meeting at 2,000 seats.
Nobody picks ServiceNow to save money. It brings implementation partners, a skill set the Atlassian admins don’t have yet, and a well-earned reputation for driving a hard bargain at renewal, which is the behavior this customer is trying to get away from. If ServiceNow’s AI features bill by consumption, the exit also lands them back on a meter. I haven’t confirmed how ServiceNow packages that today, and it’s the first thing I’d ask their sales team. So if Bob has to leave JSM, ServiceNow is the right answer. Whether he should leave JSM at all is the question, and of every move in this post, it’s the one most likely to be fueled by anger and spite rather than logic.
What you lose: You won’t be bringing SLA history in its original form, JSM automation, your Assets schema as you built it, or the direct link between a customer’s request and the engineering work item that fixes it. This is where leaving costs the most.
Jira Product Discovery: Aha!, If You Need a Discovery Tool at All
Aha! has mature strategy-to-roadmap coverage and roadmaps built for executives in a way JPD’s aren’t. By its own account the company is bootstrapped and profitable, with no venture exit clock ticking behind it, which is the closest thing to a durability guarantee in this post.
It’s also expensive. Aha! Roadmaps lists at $59 per user per month and Aha! Ideas at $39, where JPD cost next to nothing by comparison. And it cuts the built-in line from discovery into delivery that was JPD’s whole pitch.
So ask the real question first. If your product organization is real, Aha! earns its price (Productboard is the alternative if customer feedback is your center of gravity). If “ideation” meant a handful of PMs collecting intake in JPD because it was cheap, skip the category, handle intake in Asana or Notion, and drop a vendor. Just don’t rebuild discovery in custom fields inside a general work tool, which is the exact mess JPD exists to avoid.
What you lose: You leave behind your insight history, JPD’s field logic, and the live link from an idea to the delivery work that ships it.
The Scorecard
| Atlassian product | ImagiCorp’s pick | Better at the job? | Lost on the way out |
|---|---|---|---|
| Confluence | Notion (XWiki if control matters most) | Yes | Jira macros, page history |
| Jira Software | GitLab Ultimate, self-managed | Yes, for a dev-led org | JQL, automation, schemes |
| Bitbucket | Comes with GitLab (or GitHub) | Even to better | Branch permissions, repo settings |
| Jira Business | Asana (Smartsheet for tracking) | Yes, for non-technical teams | Links to engineering work |
| Jira Service Management | ServiceNow | Yes, at a much higher price | SLA history, request-to-fix link |
| Jira Product Discovery | Aha!, or nothing | Yes, at a price | Idea-to-delivery link |
Six categories, and Atlassian’s product doesn’t win one of them on its own merits. Now read the last column top to bottom: almost every entry is a connection to another Atlassian product. A feature comparison never measures that, and it’s the rest of this post.
What You Really Lose When You Leave
Interoperability
Inside Atlassian, the connections between products aren’t integrations. They’re the same platform.
A Jira work item shows up live on a Confluence page. A JSM request links to the bug that fixes it, and the agent sees the status change without chasing anyone. The development panel shows the branch and pull request beside the work item. A JPD idea shows progress from the delivery epics underneath it. Assets objects show up as fields on Jira work items. One automation engine can act across all of it, Rovo searches all of it, and one user directory, one permission model, and one admin console govern all of it. Nobody bought a connector for any of that, and none of it breaks when somebody else changes an API. This has been the great promise and delivery of the Atlassian platform for years.
Now compare that to what you’d have after migrating to five different products. ImagiCorp lands on five vendors: Notion, GitLab, Asana, ServiceNow, and Aha!. Five vendors make ten possible pairings, and every pairing you care about is an integration you buy, build, or live without. Sync tools like Exalate and Unito make a living connecting systems like these, but a sync is a copy on a schedule, with its own license, its own service account, its own field mapping, and its own way of failing when either side changes. Each one is a small project somebody owns forever.
The best evidence for this argument comes from the other side. GitLab wins the Jira Software and Bitbucket rows together because work items and code share one data model, which is why the Bitbucket move costs so little. The strongest competitor in this post wins by being a platform too.
This isn’t only an Atlassian argument, either. When Gartner surveyed 418 security leaders in 2022, 75% were consolidating vendors. Only 29% expected to spend less on licensing; 65% were doing it to improve their risk posture, and Gartner’s John Watts pinned the frustration on “operational inefficiencies and lack of integration of a heterogenous security stack.” That’s security tooling rather than work management, from Gartner’s own survey four years ago, so treat it as directional. The direction is the point: organizations that have lived with a pile of point solutions pay to get back to fewer, and they do it for integration, not savings. Bob’s exit runs the other way.
One Vendor Becomes Five
The first place five vendors shows up is the paperwork. Every one needs its own purchase order, its own renewal on its own calendar, and its own contract for legal to read. Every one needs a security review before it goes live and again every year after: a SOC 2 report to request and read, a security questionnaire, an entry in the third-party risk register. And every one is a relationship, with an account manager, an escalation path for when something breaks, and a roadmap somebody has to keep an eye on. That’s real hours from procurement, security, and the platform team, and none of it appears on a pricing page. Atlassian was one of each, give or take the Marketplace vendors, who at least bill through Atlassian’s invoice.
Then there’s who runs it all. Today one Atlassian team administers every product, with one skill set, one admin console, and a shared understanding of how the pieces connect. Notion, GitLab, Asana, ServiceNow, and Aha! have five different admin models, and very few people are good at all of them. At this size that usually means separate teams per system, or one team stretched across five specialties, each with its own training, certifications, and on-call. Either way, nobody owns the whole picture anymore, and the gaps between systems become gaps between teams.
Identity is where it gets technical, and it’s the one part of this post you can use whether you ever leave or not. The list that matters is short and hard: SAML or OIDC for sign-in, SCIM v2 with group push so a terminated employee loses access without anyone filing a ticket, session revocation so access ends when you say so rather than at the next token expiry, and audit event streaming to your SIEM.
Now multiply that by five. Five SSO configurations, five provisioning connections, five audit logs, five retention policies. Most of the open-source options above offer SAML through a community extension and no SCIM at all, which is identity work hiding inside an FTE estimate nobody counted. In fairness, Atlassian isn’t spotless here either. Guard Standard, where SSO and SCIM live, comes with Cloud Enterprise at no extra cost, but native SIEM integrations sit in Guard Premium, an add-on on top of Enterprise.
Five vendors is also five chances to have the terms changed on you, and open source isn’t a shelter either. Every Data Center admin has touched the proof. If you ever ran Jira or Confluence on MySQL, you hand-copied the JDBC driver into the lib folder yourself, because Atlassian’s own documentation says licensing constraints keep it from bundling MySQL or Oracle drivers. Both of those, as it happens, now belong to Oracle. Open source comes with terms, and the terms follow the owner. When Oracle bought MySQL along with Sun, MySQL’s creator forked it into MariaDB. OTRS stopped maintaining its free Community Edition, and Terraform, Redis, and Elastic all relicensed. What differs is what happens when you say no. Refuse a SaaS renewal and the instance stops. Refuse an open-source relicense and you keep running what you have, unsupported, for as long as you’re willing to carry it.
Don’t Expect a Cheaper Bill
Here’s what ImagiCorp signs up for on the way out:
- Parallel licensing. For 18 to 30 months, they pay Atlassian and the new vendors at the same time, because nobody sane moves 2,000 seats in a weekend.
- Five enterprise contracts, most of which only quote through sales.
- ServiceNow, plus the implementation partner that comes with it.
- Aha! at list price, replacing a tool that cost next to nothing.
- Integration tooling for the pairings they can’t live without, and someone to maintain it.
- Admin headcount, possibly a team per system: people to run self-managed GitLab, ServiceNow specialists they don’t have yet, and owners for everything else.
- Retraining for 2,000 people.
Against that, the exit saves the Atlassian bill, eventually, and whatever the step meter would have charged after December 3. Atlassian hasn’t published the per-step overage price yet, but my read is that for most shops it would have to be extraordinary to outrun ServiceNow alone.
So what does the money buy? Vendor diversification, and an end to a meter they couldn’t forecast. It doesn’t buy savings. It mostly doesn’t buy control either: GitLab self-managed is the exception, and the other picks that offered control were the ones that couldn’t get signed.
Wrapping Up
Back in 2022, answering a reader’s question, I compared Atlassian’s deployment decisions to a forest canopy: when a big tree falls, smaller trees race for the light. Server’s end did that for tools aimed at small and mid-sized teams, and it took years. Data Center leaves a narrower gap, a name a CIO recognizes that also runs on your own hardware, and whatever grows into it won’t be there before Bob has to decide.
You can leave Atlassian. Every product in this post has a competitor that does its own job better. What Atlassian sells that nobody else does is the space between the products: one identity, one permission model, and work that links across tools because it was never in separate tools to begin with. Leave, and you buy that back one integration at a time, from five vendors, at a higher price.
So here’s something to do this week whether or not you ever leave. Open Atlassian Administration and look at your identity provider connection. Check whether user provisioning is on, which groups sync, and whether the last few people who left your company lost access automatically or because somebody filed a request. Then list the five non-Atlassian tools your teams use most and ask each the same four questions: SAML or OIDC, SCIM v2 with group push, session revocation, and audit streaming to your SIEM. It takes about twenty minutes, and the first “no” tells you where your next audit finding is coming from.
I’d like to know which of those four your stack fails first. And if you’ve moved a real instance of any size off Atlassian, I’d especially like to hear what the plan missed, because that’s the part desk research can’t tell me.
Until then, this is Rodney, asking: have you updated your Jira issues work items today?
Enjoyed this one? These posts are free and always will be — but if this saved you a headache or taught you something worth keeping, you can drop a tip in the Ko-fi jar. No paywall, no subscription, no catch. Just a thanks if the writing earned it.
→ Support The Jira Guy on Ko-fi
Discover more from The Jira Guy
Subscribe to get the latest posts sent to your email.
