That's not something most people in this industry say out loud. Migrations are brutal. They're politically charged, technically unforgiving, and they have a way of exposing every shortcut an organization has taken over the past decade. You're moving hundreds of gigabytes of data — projects, issues, pages, attachments, custom fields, workflows, automations, app configurations — from infrastructure you control to infrastructure you don't. One wrong move and you're explaining to a room full of stakeholders why 40,000 Jira issues lost their attachment links.
And yet, I love them. Because when you pull one off, the impact is lasting. You've taken an organization from a platform that's dying to one that's evolving. You've untangled years of technical debt. You've given teams tools they didn't know they needed. That feeling at the end, when the data checks come back clean and the users start working in Cloud without missing a beat — there's nothing quite like it.
I've done more than ten of these now. I was there, briefly, during the Server end-of-life wave — when Atlassian killed Server in February 2024 and thousands of organizations scrambled to move to Data Center or Cloud. Today I'm doing the same work, except this time I started at the beginning and my appetite is immense. Data Center is next. The clock is ticking. And most organizations are not ready for what's coming.
This post isn't a migration guide. It's not a feature comparison chart. It's the truth as I see it — subjectively, yes, but informed by more hands-on migration experience than most people will accumulate in a career. Including, frankly, some of Atlassian's own engineers.
Data Center Is Dying. This Is Not Speculation.
On September 8, 2025, Atlassian announced the "Ascend" program — a polished name for what is, in plain terms, the death sentence for Data Center. Every major DC product — Jira Software, Confluence, Jira Service Management, Bamboo, Crowd — hits end of life on March 28, 2029. On that date, your DC instance goes read-only. You can look at your data, but you cannot create, edit, or collaborate on anything. It's a museum piece.
The milestones between now and then are already passing. December 2025 already came and went — no new DC Marketplace app submissions accepted. March 2026 closes new DC license sales to new customers. March 2028 stops all DC license changes entirely. And then, March 2029, the lights go out.
Here's the part that stings. In 2022, Atlassian published a community article explicitly stating they had no plans to end-of-life Data Center. Three years later, that promise evaporated. Organizations that invested heavily in Server-to-DC migrations specifically because of that assurance now face a second forced migration. The trust damage is real, and I've sat in rooms where stakeholders bring up that 2022 statement with justified frustration.
But frustration doesn't change the timeline. The deadline is firm. And if you're reading this in early 2026, you have roughly three years. That sounds like a lot. It isn't.
Why Atlassian Has No Choice
To understand why waiting is foolish, you need to understand why Atlassian is doing this. It's not malice. It's not greed — though the pricing strategy certainly isn't charity either. It's necessity.
Atlassian's Cloud started as a plaything. In the early days — 2009, 2011 — Cloud was essentially hosted Server. Same codebase, same features, same limitations. It was an afterthought. Something small teams used when they didn't want to manage their own infrastructure.
Somewhere along the way, Cloud became the main product. The divergence accelerated around 2017 with the Trello acquisition, gained momentum with the October 2020 "cloud-first" announcement that killed Server, and became irreversible with the acquisitions that followed: Loom for async video, The Browser Company for the Arc browser, and a string of AI and developer-focused companies. Every single acquisition has been cloud-native. Not one has added on-premises capability.
Today, Atlassian delivers roughly 8,000 cloud deployments per month. Rovo — their AI platform with search, chat, and agents — is cloud-only. Atlassian Intelligence, Compass, Goals, Focus, Jira Product Discovery, Atlassian Analytics — all cloud-only. The Teamwork Graph, tracking over 100 billion objects — cloud-only. At Team '25, they made Rovo available to all Cloud customers at no additional cost. Over one million monthly active users are already using AI features that will never touch Data Center.
Atlassian cannot maintain two massive ecosystems. The R&D investment required to keep DC at parity with Cloud would be astronomical, and it would slow down the cloud innovation that's driving their growth. Their transformation is long-term — five to ten years in the making — and for it to succeed, Data Center must die. That's the honest truth of it.
Ninety-nine percent of Atlassian's 300,000+ customers already have some Cloud footprint. The remaining holdouts are overwhelmingly enterprise organizations with complex environments, heavy customization, and — critically — stakeholders who are afraid.
Migrations Are Imperfect. This Is the Core Truth.
Here's what nobody in the Atlassian partner ecosystem wants to say clearly, so I will: Atlassian migrations are imperfect. Not by design, but by necessity.
The Jira Cloud Migration Assistant handles core data — projects, issues, users, workflows. The Confluence Cloud Migration Assistant handles spaces, pages, attachments. But the gaps are significant. Certain custom field types don't migrate at all. Non-native workflow functions — post-functions, validators, conditions — get silently skipped. User mapping requires every account to have a unique email address, which means organizations with LDAP or Active Directory need to overhaul their identity management before migration even begins.
The tools don't handle Marketplace app data. Each vendor is responsible for their own migration path, and the quality varies from excellent to nonexistent. ScriptRunner — the most widely used customization tool in the ecosystem — fundamentally changes between DC and Cloud. DC's ScriptRunner accesses the Java API directly. Cloud's version works through REST APIs with significant limitations. No scripts migrate automatically. Every single one requires manual rewriting. Enterprise instances commonly run fifty or more Marketplace apps, and each one needs individual assessment across five dimensions: does a Cloud version exist, is there feature parity, is there an automated migration path, what manual work is needed, and how does pricing change.
The Confluence editor is fundamentally different. API rate limits that don't exist in DC will break heavy integrations. Backup flexibility decreases. Direct database access disappears. Some community admins report Cloud feeling more sluggish than their tuned DC instances. These aren't deal-breakers — they're trade-offs. But they're real.
And this is where I need to be brutally honest about something: Atlassian doesn't always know best.
I know that sounds harsh. But they're still just people. Their migration tools are improving, their support is getting better, but the customer consistently expects that Atlassian has all the answers. They don't. I've encountered migration scenarios where my experience — accumulated across ten-plus migrations with wildly different environments — provided solutions that Atlassian's own support teams hadn't seen before. Not because they're incompetent, but because no single engineer sees the breadth of edge cases that a migration specialist encounters in the field. This isn't arrogance. It's pattern recognition earned through repetition.
The Two Types of Stakeholders
In my experience, organizations split into two camps the moment migration becomes real.
The first camp understands that the bandaid needs to be ripped off. These are my favorite migrations. The stakeholders have done their analysis. They understand the compromises. They know that some app data won't migrate perfectly, that some workflows will need redesigning, that users will need retraining. They've accepted that a 95% migration executed decisively is infinitely better than a hypothetical 100% migration that never happens. They set timelines, they make decisions, they move.
The second camp is paralyzed by fear. And I understand why. These are people whose names are attached to these systems. When Jira goes down, their phone rings. When Confluence loses data, they're in the incident review. Migration represents existential risk to them — not to the organization, but to their career. So they hold. And they hold. And they hold fast.
They want perfection. They want every single app migrated with zero data loss. They want every workflow replicated exactly. They want every custom field, every post-function, every ScriptRunner script to work identically in Cloud. They want guarantees that Atlassian and their migration partners cannot provide, because the guarantees don't exist.
Is this useful? No. It's actively harmful.
Because here's what happens: when someone like me joins a migration, I bear the limited responsibility of delivering a high-quality migration with zero data integrity loss. That's my job and I take it seriously. But "zero data integrity loss" is relative when the platforms aren't identical. Atlassian's apps and the third-party Marketplace apps don't have a perfect migration path. It's a compromise. It has always been a compromise. And when stakeholders refuse to accept that compromise, the project stalls.
I have watched — and I am not exaggerating — a migration that to this day still struggles to get Confluence out of Data Center. It's been more than a year and a half. Jira made it to Cloud, but Confluence sits there, stuck in an endless loop of reassessment, re-testing, scope creep, and stakeholder indecision. It is a tragedy. An absolute atrocity. If someone in that organization drew a line and tallied the money spent — the dual licensing costs, the consultant hours, the opportunity cost of teams stuck on aging infrastructure, the internal meetings that produce nothing but more meetings — I am sure someone would have a stroke on the spot.
But that's the thing about these projects. They fly under the radar in organizations with good, steady financial numbers. The bleed is slow. The cost is distributed across enough budget lines that nobody sees the full picture. Until something cracks — a security incident, a compliance audit, a pricing shock, a critical app losing DC support — and then all hell breaks loose.
The Financial Math Is Merciless
Data Center licensing costs are rising systematically. Atlassian raised prices roughly 25% in February 2025 and another 15% in February 2026. Legacy "Advantage Pricing" customers are seeing hikes of up to 40% as their rates align with standard list pricing. Some organizations report DC costs reaching three times their previous Server costs.
During migration — which takes nine to eighteen months for most enterprises — you pay for both DC licenses and Cloud subscriptions simultaneously. Atlassian offers mitigation through step-up credits and dual licensing programs, but parallel licensing remains a significant line item.
Industry estimates suggest organizations that delay migration lose roughly $500,000 annually per thousand users in missed productivity, unnecessary infrastructure spend, and avoidable legacy costs. DC administrators typically spend fifteen to twenty hours per week on infrastructure management — patching, performance tuning, backup management — representing $75,000 to $100,000 annually in labor costs that largely disappear post-migration.
And every quarter on DC is a quarter without Rovo, without AI-powered workflows, without real-time collaboration features, without the thousand-plus new features Atlassian delivers to Cloud annually. The opportunity cost compounds silently.
The Server EOL Taught Us Everything We Need to Know
February 2024. Server end of life. I was there — briefly, not as intimately as I am now with DC migrations. But I saw enough.
Organizations that waited until the final months faced severe consultant bottlenecks. Partners who normally charged reasonable rates could suddenly name their price. Migration quality suffered because compressed timelines don't allow for proper testing cycles. Three to four test migrations is the minimum for enterprise environments. Organizations doing it in a rush got one, maybe two, and accepted whatever came out the other end.
The DC sunset is going to repeat that pattern at larger scale. DC environments are more complex than Server environments were. They have more customization, more apps, more data, more integrations. And there are thousands of enterprises that need to move within a narrowing window.
The capacity crunch for migration partners will be severe. FastShift program slots — Atlassian's accelerated migration service — will be contested. Marketplace app vendors will be overwhelmed with migration support requests. And organizations that haven't started will find themselves competing for resources with everyone else who also waited.
What I Actually Tell My Clients
Here's the advice I give, straight:
Stop waiting for perfection. It doesn't exist. Not for Atlassian migrations, not for any enterprise platform migration. The question isn't "can we migrate with zero compromises?" The answer to that is no. The question is "what compromises can we live with, and how do we prepare for them?"
Analyse ruthlessly. Inventory every app. Classify them: migrate as-is, migrate with manual work, find alternative, deprecate. Be honest about which apps are actually used versus which apps someone installed three years ago and forgot about. I've seen instances with forty installed Marketplace apps where fifteen haven't been touched in over a year.
Accept the compromises and choose the least evil. Some app data won't migrate. Some workflows will need redesigning. Some users will complain. Plan for it. Document the known gaps. Create post-migration remediation plans. Stage the situation for potential shortcomings instead of pretending they won't exist.
Set a timeline and stick to it. Every migration I've seen succeed had a firm deadline that someone with authority enforced. Every migration I've seen fail had a timeline that kept sliding because stakeholders wanted "just one more round of testing" or "just a bit more time to evaluate alternatives." The testing is important. The evaluation is important. But at some point, you have to go.
Start now. Working backward from March 2029 — enterprise migrations take twelve to eighteen months minimum. Assessment and planning take another three to six months. Partner selection and procurement take time. If you want a thoughtful, well-executed migration, you should be in active planning by now and in execution by mid-2027 at the latest. That's not scaremongering. That's arithmetic.
The Honest Bottom Line
This article probably sounds grim. Good. It should. Because the reality of Atlassian migrations is grim — not because Cloud is bad (it isn't — it's genuinely better for most organizations) but because the path from DC to Cloud is imperfect, and the industry has done a poor job of being honest about that.
Atlassian wants people off Data Center because maintaining two massive ecosystems has become an impossible feat. Cloud was their plaything that became their future. Their transformation is five to ten years in the making, and they're betting the company on it. For that transformation to succeed, Data Center must die. That's not opinion — it's strategy you can read in every acquisition, every product launch, every earnings call.
The migrations are imperfect because the platforms diverged. Not recently — they've been diverging for years, and the gap has become a chasm. A perfect migration path would require DC and Cloud to be the same product. They aren't. They haven't been for a long time. And they never will be again.
So what do you do? You accept the compromises. You choose the least evil. You get on with it. You prepare for shortcomings instead of pretending they won't exist. You execute, you iterate, you improve post-migration.
Or you wait. You hold and you hold fast, convinced that perfection is just around the corner. And you watch the costs mount, the window narrow, the partner availability shrink, and the deadline approach with the same inevitability it always had.
Data Center dies on March 28, 2029. There's no going around that.
Dear customers — stop wasting time. Analyse and adapt. That is the best advice I have.
