Migrating to Atlassian Cloud is not only about transferring projects, users and data. You have to decide what should migrate, adapt what cannot be carried over as is, secure the cutover and prepare the new ways of working. BleuLemon supports organisations in migrating Jira, Jira Service Management, Confluence and the other tools of the ecosystem to Atlassian Cloud, from the analysis of the existing estate through to release, adoption and Run.
Atlassian Platinum Solution Partner · ITSM Specialized · Alongside IT departments since 2008 · Paris and Lyon
Atlassian has published a precise end-of-life schedule for Data Center.
End of Data Center sales to new customers, start of licence changes.
Last purchase or last extension for existing customers.
End of life takes effect, switch to read-only.
The scope covers Jira Software, Jira Service Management, Confluence, Bamboo, Crowd and the Data Center apps. Jira Align Data Center and Bitbucket Data Center are out of scope.
This deadline does not mean migrating in a rush. Quite the opposite: the time you have is a strategic asset.
An old instance is far better cleaned up, simplified and prepared over several budget years than in the last months before the deadline.
Waiting steadily narrows the options: app vendors invest more in their Cloud versions, teams keep spending time on Data Center upgrades, and new Atlassian features arrive in the Cloud first.
| Criterion | Jira Cloud | Jira Data Center | Jira Server |
|---|---|---|---|
| Hosting | Atlassian infrastructure | Your infrastructure or your host | Your infrastructure |
| Operation, updates | Atlassian | Your teams | Your teams |
| Deep customisation | Limited to the APIs, Forge or Apps | Open, down to the plugin code | Open |
| Data residency | Choice of regions, depending on plan and product | Wherever you install it | Wherever you install it |
| Marketplace apps | Cloud catalogue, with sometimes partial equivalents | Data Center catalogue | Frozen catalogue |
| Licence horizon | No announced end date | Last purchase 30 March 2028, read-only 28 March 2029 | Out of support |
Two Atlassian programmes support the cutover: FastShift, which brings a typical migration down from 12 to 16 months to 2 to 6 months, from 1,000 users with a Cloud subscription, and Ascend, which provides resources, schedules and documentation. We draw on either one, depending on your eligibility.
Our five-stage approach, understand, scope, deploy, drive adoption and keep it alive, remains the through line. For an Atlassian Cloud migration, it breaks down into 12 operational steps, from the inventory of the existing estate through to adoption and Run.
The aim is not only to succeed with the technical cutover, but to control the scope, prepare the teams and ensure service continuity before, during and after the migration.
Products, versions, nodes, volumes, inbound and outbound integrations.
We list every app, its vendor, how it is actually used and above all the process it supports. The question is not only whether an app exists in Cloud, but what it really does in your organisation.
We analyse the functional gaps, the technical constraints, the risks and any blocking points. This analysis identifies what can be carried over directly and what will have to be adapted.
We decide with you what migrates, what is archived, what is decommissioned and what has to be reworked.
Standard, Premium or Enterprise, genuinely active users, data residency region and security needs. Licences are sized on the target scope, not simply on what exists today.
Dormant accounts, closed projects, orphaned attachments, duplicates, custom fields that have become useless. A migration is also an opportunity to simplify.
Directory, single sign-on, automatic provisioning, groups and roles.
Workflows, automation, reports, scripts or apps with no direct equivalent have to be adapted to the Cloud model. We aim to preserve the use, not necessarily to reproduce the historical technical mechanism exactly.
We carry out a first complete migration in a test environment. It measures the real duration, detects the anomalies and reveals the gaps between theory and how the instance actually behaves.
We repeat the migration as many times as needed until the result is stable and predictable enough. We aim to reach the cutover with a proven procedure, not one that is assumed to work.
Big bang or wave-by-wave migration, freeze window, communication, transfer of the last data and acceptance testing. The strategy depends on the scope and on the level of interruption you can accept.
Training, user support, dealing with irritants, updating the knowledge base, decommissioning Data Center and follow-up after the release.
A successful migration is not judged solely on the data having arrived in the Cloud. It is also judged on the teams' ability to get back to work effectively.
Migration rehearsals: what really secures the cutover
The testing stages are often underestimated. Yet a cutover date is only credible once you know how long the migration takes, which actions fail, how to fix the problems, how long acceptance testing takes and how to react to the unexpected.
Each rehearsal reduces the uncertainty.
Operational continuity cannot be decreed. It is prepared.
The duration depends mainly on the size of the instance, the number of applications, the level of customisation and the security constraints.
| Phase | Steps | What it produces | Observed duration |
|---|---|---|---|
| Scoping | 1 to 4 | Scope settled, the fate of each app decided, trajectory costed | 2 to 4 weeks depending on the size of the instance |
| Preparation | 5 to 8 | Data cleaned, identities aligned, adaptations made | 4 to 8 weeks, apps included |
| Rehearsals and cutover | 9 to 11 | Migration duration measured, anomalies handled, acceptance signed off | 2 to 4 weeks, migration rehearsals included |
| Adoption and Run | 12 | Teams supported, Data Center decommissioned | 4 to 6 weeks after cutover |
Observed support costs range from €15k to €40k excl. VAT depending on the user tier; replacing Marketplace apps accounts for 20 to 30% of the budget. This is indicative and needs to be confirmed at proposal stage.
At an international software vendor, moving Jira, Jira Service Management and Confluence took around six months. Bitbucket stayed out of scope, by the client's choice. A scope you have chosen is better than a scope you have inherited.
Not every Data Center app has a Cloud equivalent, and where one exists, the way it works or its data model may differ. So we start by understanding the process each app carries. Some will be migrated. Others replaced. Some features can be taken over natively in Atlassian Cloud and others will have to be rethought.
An old Data Center instance often carries dormant accounts, legacy groups and permissions inherited over the years.
The Cloud bills on the basis of active users, among other things: cleaning up identities is therefore a security, an organisational and a licensing matter at once.
The number of seats has to be decided before the migration, not discovered on the first invoice.
Moving to a Cloud service changes the nature of the security case. Logging, access restrictions, encryption, API tokens, identity, data location and third-party applications all have to be analysed in the new context.
Each app also adds one more supplier to the processing chain. For organisations subject to specific regulatory requirements (DORA, NIS 2), these subjects are worked on from the scoping stage with your security and compliance teams.
What this looks like in the field
At a logistics client, whose case remains anonymised, script-managed components gave way to an Assets matrix. One blocking point took nearly a year, nine months of it with an Atlassian developer and no solution. Hence step 2, never the day before the cutover. On this front we work in particular with Appfire and XBlend.
See Atlassian licensing.
Atlassian Cloud is an online service operated by Atlassian. That sentence sets the limits of the exercise.
What is possible. Depending on the products and the plans, it is possible in particular to:
Our solution Aquarius can, for example, extract and archive sensitive Jira projects into a self-contained archive.
What is not. Atlassian Cloud is not a Cloud run by the host of your choice.
Data whose constraints require it to stay in a specific environment therefore cannot simply be transferred into Atlassian Cloud.
On some projects, the right answer may be to keep a scope outside the Cloud for a time, or to choose another solution for certain data. We have already kept two Confluence spaces in-house, by the client's strategic choice, alongside a migrated scope.
The migration therefore has to be decided scope by scope, not as a single monolithic move for the whole organisation.
Data residency is offered in the European Union, in Frankfurt and Dublin, for Jira, Confluence and Jira Service Management on the Standard, Premium and Enterprise plans. Atlassian publishes its SOC 2 and ISO 27001 attestations.
Legal sovereignty is about the applicable law. Operational sovereignty is about something else: continuing to operate without your supplier.
The real test of sovereignty is not going in with a supplier. It is getting out.
BleuLemon, a French consultancy (Paris, Lyon) and Atlassian Platinum Solution Partner since 2008. Six variables determine the cost and duration of your migration.
Two entry formats put them all on the table. Choose according to the scale of the subject.
Is our Atlassian environment still suited to our uses and our challenges?
How do you leave Atlassian Data Center without service interruption or loss of efficiency?
Our framework has five stages: understand, scope, deploy, drive adoption, keep it alive. A migration is judged on the last one.
A question that finds no answer here is dealt with in a thirty-minute conversation, about your actual context rather than a general case.
Talk to an expertA migration to the Cloud does not necessarily reproduce the Data Center environment exactly.
Some functions exist in a different form, some applications have to be replaced and some customisations have to be rethought.
That is precisely why the work begins well before the cutover.
The cost depends on the number of users, the volumes, the apps installed, the level of customisation, the security constraints and the cutover strategy.
So we start by qualifying these variables before pricing the migration.
A migration can take a few months, or longer for the most complex environments.
The deciding factor is not only the volume: apps, integrations, permissions, customisations and security requirements weigh heavily on the schedule.
We analyse them one by one.
Some have a direct Cloud equivalent, others require a different app or a rebuild, and some features may now be covered natively by Atlassian.
The right goal is to preserve the useful process, not necessarily the legacy app.
Atlassian offers data residency options depending on the product and the plan subscribed to.
The choice has to be examined against your security and compliance requirements, and against the third-party apps in use.
Yes.
A migration can be organised as a single cutover or in several waves, depending on the products, the populations, the dependencies and the tolerance for service interruption.
The choice is made during scoping.
We start by determining which of them still meet a real need.
Those that must be kept are adapted to what the Cloud allows; those that are no longer useful can be simplified or removed.
A migration is also an opportunity not to reproduce in the target all the complexity of the existing estate.
Going further: Change management·Jira archiving before migration·The Atlassian partnership
