Atlassian Data Center end of life: do not treat it as an ultimatum.

In September 2025, Atlassian announced the end of life of its Data Center offerings for Jira, Jira Service Management and Confluence. Between that announcement and March 2029, the vendor is phasing the offering out gradually and leaving customers time to organise themselves.

The difference between the end of Server and the end of life of Atlassian's Data Center offering.

Some of you have already been through this in your IT department, when Atlassian discontinued its Server offering. At that point, the stakes were almost entirely financial.

Moving from Server to Data Center could amount to nothing more than a change of licence key. You inherited a few extra features, but the existing solutions were not called into question. The customisations already in place carried on working, apart from a few plugins that did not follow, and beyond a higher invoice, the teams were not greatly affected.

This time, by contrast, the technology leap is a large one and the investments already made will not necessarily be replicated and preserved. The sooner that is understood, the more room there is to anticipate and act.

There is still time before March 2029, so let us use it.

In this article, we set out our point of view and a few pieces of advice, so that this opportunity does not turn into a time bomb.

I. Start with the internal story, not with the technology

The first question that arises is political and organisational.

How will you present this project to your organisation?

At BleuLemon, we see two possible approaches. Neither is better than the other, and today you can still choose: the longer you wait, the greater the risk of having no choice left.

The “external driver” option: the choice of tool is imposed on us

The project is presented as a direct consequence of Atlassian's decision: “The vendor is discontinuing its offering, we have to change tools”.

Advantages

Limitations

- The rationale is simple and easy to explain.

- The project is seen as a necessary evil and will probably rally few people.

- The project is carried entirely by the IT department, on a logic of compliance and service continuity.

- Involvement from the business is minimal. Their expectations are high, because the change risks a loss of features with no immediate gain.

- Scoping is faster. It is not always straightforward: how long the solutions have been present in the organisation and, for some of them, an initial rollout as shadow IT with no governance do not make it easy to identify every use case.

- Sponsorship is hard to find, and that complicates the budget trade-offs.

The “internal driver” option: a transformation programme you own

The project is presented as an internal decision to give the organisation a fitting solution for product development and service management. Here, the idea goes beyond moving an existing service in order to replicate it in another solution. It consists in defining an ideal target, in line with the state of the art, together with every user department in the organisation. The solutions are then adapted accordingly, taking the existing estate into account.

The questions to ask yourself:

1. How do we want our teams to work in 5 years?

2. How can we better align IT, Product, the business and Support around one coherent system of work?

3. How do we bring AI into our processes and automate them as well as possible?

Advantages

Limitations

- A unifying business case is built and put forward, justifying the investments through the expected returns in productivity, quality, time to market, security and compliance.

- Scoping is more complex

- Genuine commitment from the business, which takes part in the choices

- Sponsors are needed beyond the IT department (business, finance, HR)

- Better alignment with the organisation's strategic priorities such as growth, rationalising resources, CSR, FinOps and so on

- Trade-offs are more sensitive

- Implementation takes longer

Get moving as soon as possible

At BleuLemon, we see that the clients who choose the “internal driver” option get far more value out of this compulsory step.

While option 1, the “external driver”, can still be deferred, we advise starting the project quickly, to give yourself the chance to run a transformation programme you own. Starting quickly is necessary because we are already at the edge of reasonable lead times, but there is still time to do it well.

II. From Atlassian Data Center to Cloud: which solution should you favour?

Atlassian's own messaging naturally steers its customers towards its Cloud offering. That is indeed the solution that looks most natural, all the more so since the vendor concentrates its entire R&D effort on it. So, on the face of it, customers happy with Data Center would stay happy after a switch to Cloud.

The advantages of Atlassian Cloud:

• functional continuity with the solutions already in place, Jira, Jira Service Management, Confluence and the rest.
• continuous innovation, such as Atlassian Intelligence recently, the complementary products (Loom, Rovo) and the Cloud-only features.
• a lighter operational burden.

There are still cases where other options make more sense:

• in some heavily regulated or very specific contexts, an alternative solution or a hybrid architecture may be preferable.
• constraints of sovereignty, latency, advanced integrations or bespoke developments may call for a wider study of the business tools market.

Atlassian tools can also overlap with those already present in the organisation when new Cloud features are rolled out. Gitlab, test management solutions and ServiceNow are cases in point.

The end of life of Atlassian Data Center is the occasion to ask again what place and what purpose all these solutions have, in order, ideally, to arrive at a simplification and, potentially, at savings.

At BleuLemon, our recommendation is not to presume the target solution at the very start of the project. The choice should follow from:

• the story you have chosen to promote internally (an imposed replacement, or a transformation you have chosen)
• the analysis of the risks, the constraints and the ambitions
• the business case you want to carry.

III. The first leg of the journey: a scoping project

The scoping project is the first step we recommend, whichever option is chosen. It is not merely an upstream phase, it is the first step of the change project itself.

The four deliverables of this project are:

• the name and the pitch of the project,
• the first risk analysis,
• the map of the people involved,
• the material for writing the future RFP.

The name and the pitch of the project

The project has to be embodied. You are going to present it to the stakeholders, and you will often find yourself talking about it in all sorts of circumstances: in a workshop, in a formal presentation, in the lift, in the canteen. A solid, concise and readable pitch will help you set the scene.

The goal is that everyone understands, above all, why this project exists, in less than 10 seconds and in a single sentence.

So you need to have:

• a project name that speaks to the organisation and not only to the IT department
• a formalised rationale, either: - business-oriented (productivity, rationalisation, alignment of practices, risk reduction, efficiency)- centred on a change of tool, if the choice is to stay with a “minimalist” project

The first risk analysis

The first risk analysis is what guides:

• The choice of solution: Atlassian Cloud, another solution, a hybrid one, and so on
• The structuring of the project into phases, pilots and a migration trajectory
• The level of support to plan for, broken down into communication, training, run support, governance and so on

This part must cover:

• Technical risks (performance, integrations, security, compliance)
• Operational risks (service outage, recovery after incidents, process continuity)
• People risks (buy-in from the teams, loss of skills)
• Contractual and financial risks (licences, commitments, vendor dependency)
• Regulatory risks (target certifications, regulations specific to your market)

The main goal is to avoid hasty decisions and to build an informed choice of solution, rather than considering only a reproduction of the existing estate in the Cloud, sometimes called “lift and shift”.

This step should establish the type of change involved (cultural, organisational, tooling, and so on) in order to size the change effort to run.

Mapping the people affected

Migrating Atlassian Data Center solutions to the target solution is never only a matter of infrastructure or features. It involves people:

• The project, product and development teams
• The support teams and the service centres
• The business functions (marketing, operations, back office)
• The support functions (security, finance, procurement, compliance)

In every case, it is advisable to map the people concerned in order to establish:

• Who is affected, how and to what extent?
• Who are the change champions to bring on board?
• Who needs a different kind of support?

This map feeds directly into the change management plan (communication, training, coaching, support and handling of friction points).

The material for writing the request for proposal (RFP)

We advise in every case drawing up an RFP that will give the project its frame. This RFP is used to define the requirements to be covered and can serve as the basis for a wider consultation.

Scoping must produce the material needed to write the document:

• either drawn from the business case;
• or drawn from the current use cases.

Non-functional requirements: security, compliance, data residency, performance, scalability, integrations.

Change management requirements: support, training, communication, governance.

Evaluation criteria: total cost, risks, roadmap, vendor and integrator support, CSR commitment, and so on.

This RFP must be neutral with regard to the solution, so that several target scenarios can be compared honestly.

IV. BleuLemon supports you as you leave Atlassian Data Center

We are used to complex environments, particularly those of the business functions concerned by the Atlassian solutions.

We run the complete cycle in a single long period of immersion: discovery, assessment, strategic design and iteration.

We stay at the heart of the problem until we understand it from another angle, through our outside view. And once the underlying problem is clearly laid out, we build your project with you. Not a technical integration. A solution. Tailored. Specific. We leave the beaten track when that is what it takes.

Our role in this project to leave Atlassian Data Center covers:

• running the workshops needed to establish the scope of the project;
• analysing your existing estate (instances, usage, integrations);
• assessing the Cloud and alternative trajectories (internal story, risk analysis, map of the people affected and RFP material).

The aim is to use the next 3 years as a lever and not as a stay of execution, and to build a solution that is robust, effective and durable for the next 5 years.

BleuLemon supports IT departments through their transformation with freshness and quickness of mind. We help organisations unlock the collective potential of their teams, opening the way to a sturdier and more fulfilling way of organising work.