Data Center or Cloud: What’s Your Long-Term Plan?

[Namita Awasthi]

With Atlassian pushing Cloud as the future, I’m curious how others are thinking about the Cloud vs Data Center decision.

We’re currently on Confluence and Jira Data Center, and while we see the advantages of Cloud (scalability, automatic updates, ecosystem improvements), there are still some strong reasons we’re staying put (for now).

For example:

• We have deep integrations with internal systems that are easier to manage on-prem
• Performance and control are critical for some business units
• Compliance and data residency requirements are easier to enforce internally
• Some macros and plugins we rely on aren’t Cloud-ready yet

That said, we’re watching the roadmap closely and re-evaluating regularly.

I’d love to hear from others:

• Are you still on Data Center? Why?
• Have you migrated to the Cloud? How did it go?
• What are the deal-breakers or tipping points for your team?

Let’s get a thread going. Real-world experiences would be super helpful for both sides of the decision.

[Vickey Palzor Lepcha]

At some stage , I think you will want to move to Cloud , considering Cloud has more and better features. There are changes in DC too , but the amount of new features that are released for Cloud versions seem to be more and frequent.

And users at some point of time start demanding those features and would get bored with the same old DC UI and limited features.

I have been using DC for quite sometime now , and Cloud for my personal use . I must say that Cloud Version gets me excited with all its features .

And also , DC kept me 50% 60 % of the time engaged as system admin/linux , which I think eats up my time as admin when I could have been exploring more of JIRA and Confluence .

[Namita Awasthi]

I agree - most new features released are not available on DC. 

[Roger]

"At some stage , I think you will want to move to Cloud , considering Cloud has more and better features."

Unfortunately the difference in features seems artificially pushed by Atlassian. So I am reading your argument as: at some stage we have to move, because Atlassian is pushing us.

[Rolf Lader]

Hello @Namita Awasthi, 

I completely agree with you.

The same reasons you mention are also motivating us to stick with the Data Center versions. I also don't see Atlassian's cloud-first strategy lasting much longer. Atlassian's sales and profits are increasing on the Data Center side, so the executive suite will not be able to maintain this cloud-first strategy with their stakeholders for much longer.

However, this does not change the fact that the advantages of a centralized approach also bring immense benefits. The resources that a company has to invest in maintaining just one cloud version of the respective applications are already significantly lower than for the many Data Center versions. 

Therefore, I believe that the cloud approach will prevail in the long term. But not in the short or medium term.

Best regards, Rolf 

Translated with DeepL.com (free version)

[Urmo]

Today i say that been in cloud is easier than in DC because you don't need worried any security issues and update instance every random moment. Less admin time needed but downside on this is that sometimes some updates arrive so random that you are not really ready from them and when you are not also end users can be also suprised. But mostly Cloud is simple and more user-focused to use.

Migration was made with Atlassian Partner but mostly there was some stuff what did work in Server/DC but not needed anymore in Cloud. So there must take some time to clean up old mess and be ready to build new settings from scratch.

DC support cheaper way to backup today. In Cloud it is not so simple to do. Yes there is many partners ho can help to do it but it is more costly than sometimes you hope.

DC had more settings behind the front screen and today you can't have access to server side or into database. I did like use sql to make search directly from database. In cloud you can't do it.

Urmo

[Simone Kistner]

I completely agree with you. Same reasons here..... 

[Sake]

It's a shame to artificially cripple DC with not providing the same functionality as Cloud. I understand the drop of Server, but why not adding new features the same frequency as on Cloud? Maybe don't support old versions not to long, if that's to costly.
Our management are looking at the Cloud, but only because they believe it's better because of extra Features. But those Features could easily be implemented in DC, but Atlassian is choosing not to.

The reason for on-premises is quite simple; full control. We know who has access, we know when we update, we keep performance on par and we don't want to be a number when there are issues which only can be fixed when having backend access.

Also we have a lot of integrations and our servers aren't connected to the internet, we really don't want that because of control, security and regulations.

Edit: also the cost on Cloud is much higher...

[Roger]

I agree.
As I mentioned in another reply, someone wrote "At some stage , I think you will want to move to Cloud , considering Cloud has more and better features."

Unfortunately the difference in features seems artificially pushed by Atlassian. So I am reading that argument as: at some stage we have to move, because Atlassian is pushing us.

[Per Åge Sørvik]

We are still on local instances, much for the same reasons, deep integrations and missing plugins in cloud. Migrating to cloud is a big hassle for us, and would increase cost massively. 

Might as well look at migrating to something else.

[Marco Leist]

For us, the biggest pain point is the fact that Confluence Cloud does not support nested third-party macros in the new editor (https://jira.atlassian.com/browse/CONFCLOUD-70746), as we have thousands of pages that make extensive use of them. Whether this is actually a deal breaker is questionable - but it will probably lead to massive migration efforts and frustration among our users.

[Phill Pafford]

Until they offer some sort of process where I can control, very fine grain access/permissions for deployment into a private vpc, I can't use cloud without the additional setup of an actual deployment server. There is no way security team would allow a SAAS/Cloud tool to have access to deploy. While the SAAS/Cloud could kick off the build and trigger the deployment process, we need to have some sort of server, self hosted, for deployments.

Currently we run Bitbucket DC and Bamboo DC, could move to use Bitbucket Cloud but would still need a Deployment server, such as Bamboo DC or Jenkins, unless there is another option I'm not aware of.

[Dave Thomas]

I've been an administrator of Atlassian applications for almost two decades now and currently manage several large (25-30k user) data center instances. We're in the final stages of discovery with Atlassian and partners to examine migration to the cloud from a technical and business perspective, including return on investment.

For us, moving is going to be hard. We've got lots of integrations and custom plugins and we regularly do things directly in the database where the same is either not possible or not performant using the REST api or other methods. All of this needs to be redesigned and reimplemented, which is going to take a lot of time and effort. On the plus side, everything we're doing today is possible on the cloud.. just different. We'll need to re-implement many things as we shift reporting to their data lake, plugins towards Forge, and other automations towards Rovo.

Some things are easier on the cloud platform, while others are a bit more difficult. Not having to manage the infrastructure, application upgrades, disaster recovery, etc. are clearly a plus. On the other hand, management of plugin-specific data is currently more complex. Also, simple things like identity management of external users and even backups to guard against accidental deletion/modification of data is a bit more challenging.

At the end of the day, I think a move to Atlassian's cloud platform is inevitable. I don't think Atlassian will kill support for their data center instances, but they have a long history of letting products stagnate when they have another option that's preferred. To use an analogy: you're driving a nice, older car that's paid for and works well, but is showing it's age a bit. Now here comes Atlassian with a shiny new car that's better in almost every way than your old one, but ooof... the price tag (for us, our annual cost would be about 4x higher on the cloud, plus the cost to move). We faced a similar decision point when moving from single-server perpetual licenses to the annual data center licenses that were literally 10x the cost. There, we kept using single server licenses until we no longer could (for us, this came before the discontinuation of single server licenses).

The higher cost is not without benefit though: There are a large number of features and integrations that are cloud-only and that number is growing all the time. Also, the AI and other improvements on the cloud are expected to improve efficiency and productivity. When you have a large number of users, these gains can produce a good return on investment in spite of the larger expense. Our next steps are to conduct a proof of concept with a few teams to test the improvements and potential benefits while we also work on migration of reporting, integrations, and customizations. If the user experience isn't significantly better, we may defer the migration or even look at alternatives. I honestly don't expect that to happen though... In my view, it's not a question of whether to move to Atlassian's cloud, it's a question of when.

Note: my comments here are largely focused on Jira Software, Jira Service Management, and Confluence. We have other Atlassian applications as well, but they are either not available on the cloud or have strong competitors in the market.

[John Dunkelberg]

We're in a very similar place.

I'm glad you mentioned looking at alternative competitive solutions.  For people facing a steep migration cost, it indeed may be a very good time to spend time re-assessing the marketplace.  That certainly has been part of my thought process for us.

[Matt Doar _Adaptavist_]

Good summary, and what I hear from multiple organizations. One challenge is that I don't know of anything that does what Jira does at scale, or as flexibly.

[Sebastian B]

Hi @Dave Thomas

thank you for sharing this.

Would you be OK with sharing some more details about how you are going to perform the proof of concept/initial testing? What will be your criteria for choosing the teams? What do you plan to do so that some teams don't feel left out of the 'better Jira' once the rumours start spreading? 

[John Dunkelberg]

We're on DC and evaluating migration to Cloud.  As others have noted, Atlassian has been clear that they are Cloud-first for some time now.  From other comments I'd add that folks may not realize that it appears Atlassian has two quite separate codebases here, so it's nontrivial to port features over from Cloud to DC.  I recall going to one of the annual user events circa 2017 or so (I don't remember if it was called "Teams" back then) and in talking to the people at the separate Jira Cloud and (then) Jira Server booths it was really clear they were two separate teams working in two separate codebases.

That said, I am disappointed that Jira Cloud doesn't seem to have tackled some of the Enterprise scaling design issues in their fork of the code.  One that's a particular pain for us is that Versions are at the Project level, so we're seeing that Plans which span projects have poor performance pulling these together.  i.e. if you have ten projects in a Plan each of which have monthly Versions "Jan2025" thru "Dec2025" those are treated as 120 versions in the Plan, not 12.

@Namita Awasthi we also have in-house extensions for Jira to integrate with our internal applications.  We've been closely engaged with Atlassian in seeking solutions to gaps in capability in the Cloud APIs, and have made a lot of progress, but it's certainly going to be a substantial investment to port these applications.

On the third-party vendors, I think the major vendors (for us: Tempo, Adaptavist, EazyBI) are pretty much good on Cloud and starting to surpass DC, but there are still gaps fundamental to the change in platform.

[Dave Thomas]

Good point that the code bases are completely different now.  When they first split, I think cloud and data center were the same, but the entire back end is completely different at this point.   When people are (understandably) frustrated about features on the cloud not being available on DC, they may not realize it's not a task of porting the cloud code and just tweaking a few things... it's a task of re-implementing those same features on a different product.  In some cases, it's not feasible or even possible.

@John Dunkelberg - Have you guys looked at Align?  In my opinion, Jira Portfolio (now called Advanced Roadmaps and included with DC) has always been pretty terrible.  AgileCraft created a much better product, which Atlassian purchased and re-branded as Align.   It's more expensive (of course!).

[John Dunkelberg]

@Dave Thomas we'd looked at it years ago and saw it was designed to be more strictly SAFE than we operate.  Looking at it now it looks like they're advertising more flexibility there.  I just looked at the Pricing tab and that might be the killer, if indeed the only way to buy it is as part of the "Strategy Collection" and that needs to be priced against our userbase.  Even if I price it with the idea that only lead roles would have licenses that's a big pricetag.   But nonetheless good to perhaps put on the backlog to dig into more.

[Ulrich Kuhnhardt _IzymesCo_]

When do y'all think Atlassian will pull the plug on DC?

[Urmo]

I think not soon because i understand that there in globaly is very many and very big Atlassian DC customers ho is not ready to give their data into somewhere where they don't have full control over it. Maybe private cloud server will help this thing happening sooner but i'm not see that happens tomorrow or after tomorrow :)

Also last week was news that chatgpt chat was leaking into internet so is this maybe also one thing what set people think differently after that? What is in internet will be there forever and we don't have control over it.

So when you are big company and secret plans and if there is no human error anymore but only possible that AI have access and can leak it?

[Ulrich Kuhnhardt _IzymesCo_]

Atlassian will offer those customers their isolated cloud offering. I'm not sure about AI though, perhaps customers in isolated cloud can 'add-on' an isolated hosted LLM ?

[Sake]

Nothing is save in the cloud :)

[John Dunkelberg]

@Ulrich Kuhnhardt _IzymesCo_ I think the comparison I've liked by more knowledgeable people is to compare to the Jira Server deprecation.  IIRC, in that case there was a lengthy sunset period (was it 3 years?) which will give people time to either migrate to Jira Cloud or to a competitive solution.  That said, the number of on-prem competitive commercial solutions may be pretty low (and lower in the years to come).

[Roger]

I tried this prompt in several ai-models:
Provide an overview of open source alternatives to Jira Cloud and Jira Data Center, including a table with relevant columns such as type, price, key features, and integrations, making it easy to compare with Atlassian products.

Interesting to see so many products (not all are free) and informative to read about.
This is a very crude way to compare, but at least I have learned some new names.

[Rainer Pöhlmann]

Hello @Namita Awasthi

For us being an academic institution, moving into cloud will be a huge effort. Why?

• We have 2 instances with a long / very long history (> 11 years). In addition, one of them is quite large. Although the Cloud migration assistant is getting more and more better, it will not be that easy
• Our users - at least partially - are using Confluence to the very extreme: very large & complex pages, nested macros, etc. Whatever you cannot imagine, users will figure out and do. And, most of the time, successfully.
  Those things will become much more difficult if if not impossible in the Cloud. And: page loading times will definetively increase :(
• Being a swiss academic instituation with several hundred employees and several thousand students we will be committed to do a data protection assesment, not even with our own data protection officer but also with the cantonal one. This will be a long and tedious project. We're just doing it for another Cloud product currently, it's not "fun".
• Our Confluence instances are heavily integrated with other on prem systems exchanging data back- and forwards
• Cloud will be more expensive than its on prem counterparts (maybe I should not mention this here ...). And then, arguments from the management will immediate jump in: why do we need another Cloud product with partially overlapping functions if we already have the competitor inside a campus licensing contract. Difficult to invalidate ...
• Yes, Cloud does offer a lot of new features. But those also includes several ones our current on prem users do not demand for. Vice versa, some "beloved" on prem features will be missing in the Cloud. So just arguing feature wise is not the whole story.
• We currently do not see reduced administration efforts when migrating to Cloud. It simply shifts elsewhere but in sum stays comparably.

To summarize: Cloud might become inevitable, but as long as we can avoid we will try to do so.
However, for a much smaller Jira instance we will think about moving into Cloud sooner.

I hope this helps you to better understand our thoughts on this topic.

regards,
-Rainer

[John Dunkelberg]

@Rainer Pöhlmann I'm not on our Confluence team, but from this description "using Confluence to the very extreme: very large & complex pages, nested macros, etc." it doesn't sound like Confluence Cloud is ready for you yet.  We've migrated to Confluence Cloud (still have Jira on DC) and what you're describing has definitely been a pain point.  The "try converting a page to the new editor and visually inspect to see if it worked, repeat for every page" approach is rough, and it sounds like that'd be a complete non-starter for you.

[Namita Awasthi]

Thanks @Rainer Pöhlmann, for sharing your perspective. Some of the challenges you mentioned are common for us. 

[Matthew Martin]

We are mid-flight on adoption of Cloud from DC and I'd love to share my experience. I don't have an ordered list on challenges so don't read into the sorting of this list too much, and please note, this is 100% my opinion as a platform admin now with about 8 years experience in this space managing a company wide instance of Confluence/Jira @ 25K users.

• The challenge of a migration to Cloud will largely be based on your addon usage. While environmental complexities around the base data types does make things longer (think customfield numbers in Jira), in our case, it's factors like for example, remediating the no macros with bodies inside macro bodies issue for Confluence. We had a scope of almost 60K pages that required manual remediation before migration. While we are on the topics of addons:
  • The addon space in Cloud is complicated. That same pressure you feel from Atlassian to drive customers from DC to Cloud is occurring in the Cloud space itself in the addon context, however, it's from Connect types addons to Forge, and it's not pretty. Seems like Atlassian wants connect gone, and for everyone to adopt Forge, however, Forge is far from parity, and has a number of structure limitations that heavily impact on enabling an addon develop to deliver for their customers. This has not stopped Atlassian though who have even placed a financial penalty on those retaining connect style addons.
  • Aside from the work related to doing addon feature parity reviews and impact analysis tasks that are part and parcel of a review to migrate to cloud, there are still other "gotchas" that are floating around and somewhat hard to identify and tease out. For example, my organisation has data residency requirements. Initially, you might think, "How does that relate to addons? Doesn't data remain in Atlassian's cloud and adhere to your data residency requirements?". No. In order for addon developers using connect (and some forge) style addons to deliver fully featured addons, to get around some of the inherent limitations, processing and storage of your data will occur outside Atlassians cloud platform on 3rd party owned and managed infrastructure. The more addons, the more 3rd parties handling your data. This is a massive risk for us, and our organisation requires that each 3rd party be individually investigated and reviewed before we can use them. As you can imagine, the cost here in terms of time and effort is so large that it drives you to simply doing whatever you can to drop the addons which drives the value of the cloud platform down. It's tragic
  • Security features like ACL'd access exist in Atlassian Cloud, but they don't exist for your addon 3rd party vendors who now host all your rest endpoints open to the public internet with the only access vector being a valid token. Say goodbye to meeting any of your organisational device compliance checks. Death by a thousand cuts.
  • In saying all this about Cloud, the addon space is also a mess in DC. The challenges that we've faced into over the past few years patching addons, finding bugs, and trying to get them resolved has been nothing short of a nightmare as well. It has at times felt like the DC addon space is the wild-west. No insight into testing competency, quality, or validation before things get pushed out. This idea that responsibility is 100% on you as the platform owner to test is I think, irresponsible. Does the marketplace itself not serve as an innate sign of trust from Atlassian to these addon developers  (many carrying badges like "Platinum Partner")? Is it wrong to think that I should be able to adopt something that's a month old and it not carry a critical bug? What about requiring an addon developer to remove versions of their addons with bugs from the marketplace? Nope. Not worth it. Super disappointing. Sure. You can certainly make the case that that our own internal testing practices are not competent enough to pick up and validate for issues. I agree, but we've had cases where we've deployed versions that are a month-2 months old, identified a bug, and the addon vendors simply replied and said, "Yep known bug please wait for a fix or rollback". No requirement for a badge on the version, or to proactively notify customers. I hate this. 
• Performance comparisons will largely come down to how you've managed to deliver in this space in relation to your DC instance, but for us, performance is quite a lot worse. It's not a deal breaker, but that sense of snappiness is gone. Everything lazy loads, and sometimes, it can be quite a bit slower than you'd expect. 
• The Cloud feature set is obviously a massive selling point. The design is modern, there are far fewer accessibility issues which is amazing, but the discussion for us has been around, what is our net position on features after we've switched off addons, and considered the training costs, and adoption challenges. It's hard to keep users eyes on the good when they are experiencing such an impact in relation to what they might be losing. Features like Confluence whiteboards are a legitimate game changer. Wonderful, but then Confluence Cloud offers nothing in relation to technical diagrams. There are still these massive gaps in the base products, and Atlassian just tell you to acquire an addon to cover them. That's totally fine till you consider all the issues above. "Just acquiring an addon" could be the last thing you do in this life in Cloud.
• We love the fact that we won't be on DC for many reasons. Largely that we aren't going to be on the "burning platform" anymore. Atlassian has been creating rising economic and feature pressure in relation to DC. The point on the chart where the cost of DC and the cost of Cloud cross over seems to be moving closer. I won't miss having to react to the monthly patching emails.
• I better stop here and get back to work. I assume there'll be more things I identify as we get through this adoption of cloud. We are still months away from the cut over. Let me know if you want a comment on anything more specific. I know I've focussed more on the negative but that is what I care about at the moment, and what is causing me pain.

If anyone specifically wants to chat, let me know. Happy to share my exp.

[Namita Awasthi]

Thanks @Matthew Martin, your first-hand experience is really helpful. We also use quite a few add-ons. The points you mentioned will help us understand & prepare better if/when we decide to migrate.

[John Dunkelberg]

Thanks @Matthew Martin this is really valuable to hear for me as well.

[Jay Greguske]

We're through discovery and some ways into building our migration runbook and plan. We aim to be in cloud later this year. We know what needs to be done and now it's a matter of execution through a series of UATs and targeted activities. Our Jira DC instance is 20k users, and is an amalgamation of at least 4 Jira Server instances that existed a few years ago. One of those was acquired by my company in 2008, I don't actually know how long ago it was deployed.

So we have a lot of legacy, plugins, integrations, and customization. Some top-of-mind observations:

1. As others have mentioned, managing the 3rd party plugin data is harder. Atlassian's data recovery tools understand their own stack, but you're on your own to recover things like ScriptRunner configuration. Solutions exist in the marketplace, but they are pricy.
2. The cost of migrating for us is competitive with staying on DC. It's not really a factor considering DC's costs have been increasing anyway.
3. We're looking forward to new feature sets becoming available to us. We're on a Jira 9 stream, so our UIs are at least 10 years old and have seen little investment from Atlassian. I don't begrudge Atlassian as I work at a software company and backporting patches and features to a code base you forked over a decade ago is definitely a challenge.

Our current challenges are:

1. We host a public instance, and that means there are a lot of domains and new accounts being created every day. This interferes with migration rehearsals and makes connecting to our IdP a little unique.
2. The migration tool does not maintain the parent link field. We have 6 layers in our issue hierarchy, and everything above epics has no parents or children when we run a migration. We're swarming on that problem next week.
3. We have about 8 custom plugins to rebuild in Forge, and that's all net-new to our teams. 5 of them are critical to be there on day 1, so that's a concern.

[Marco Nowak]

@Matthew Martin How do you handle existing JIRA projects in DC. Can you bring them to Cloud?

[Matthew Martin]

You'll laugh but my org has determined that we will not migrate any projects from DC to Cloud. That's primarily because we've been given 6 months to get to Cloud, and it's not realistic that we can migrate the ~2000 active projects given our extensive addon usage.

We haven't yet announced this. I think it'll be about as well received as you'd imagine.

[Marco Nowak]

And what`s your plan then? Rebuild 2000 projects in Cloud and create new issues there while older issues are still processed in DC?

[Matthew Martin]

We will require our users to recreate any content they require in the Cloud environment. We will discontinue use of the DC environment (placing into read-only state) in approximately January 2026.

[Marco Nowak]

So the project owners are able to create workflows etc themselves in your company? We have a small team that does this centrally for all users. That would mean for us to re-create all projects with our team (2 people). Well....we only have about 200 projects but some of them highly integrated to other tools and/or using complex workflow solutions.

[Matthew Martin]

Our organisation has run on shared-project templates in DC.

We have a set of approximately 6 projects, and we have a form that enables users to self-service create using any of these as the shared template.

We intend on operating this same way in Cloud as it enables consistency across the userbase.

[Marco Nowak]

Well...that was a wise decision by you / your company. We offer nearly every stakeholder his/her own project with individual workflows, functions etc. That gave us high flexibility for our demands but....cause a lot of administrative effort and the problem, that an automated Cloud migration is impossible, now.

[Matthew Martin]

It was not well received initially but we had executive support, and the ability to disable project creation, so everyone had to get on board. In saying that, after almost 5 years operating in this fashion, we still have about 5% of projects that are custom that have successfully fought for and retained their non-standardised projects.

[Jay Greguske]

We have this too. It's about 10% for us. They're either products that don't have to integrate with the rest of the portfolio (the coupling is low or non-existent) or they're pure R&D, so it's not worth the effort to standardize them.

[Marco Nowak]

In the past we tried to migrate to Cloud but we were unable to even migrate our most simple JIRA project without producing huge manual effort. This and the fact that we trigger some of our DBs from JIRA leads us to the decision, not to use Cloud.

Also, the additional Cloud features do not justify the additional costs for us.

[Marco Nowak]

@Namita Awasthi 

In your analysis: despite your mentioned problems, were you able to migrate your existing projects? For us it was impossible. Means: if we want to use Cloud, we would have to re-create all existing projects and start from scratch and use DC and Cloud for a longer time in parallel. 

[Namita Awasthi]

Hi @Marco Nowak,

We are still on DC; haven't started migrating as yet. Migration would mean a lot of rework for us.