Viamedis: an anonymisation POC before committing to the Atlassian Cloud migration.
Viamedis, a player in healthcare third-party payment, entrusted BleuLemon with preparing its Atlassian Cloud trajectory. The engagement covered two stages: an audit of the existing environment, then a POC for anonymising sensitive data. The POC settles technical feasibility before any migration commitment.
Banking, Finance & Insurance, healthcare third-party payment · Audit, anonymisation POC, Cloud trajectory
Key results.
The POC settles technical feasibility before the migration, not after. Every statement on this page comes from an engagement document.
The context.
Viamedis operates in healthcare third-party payment. The data its teams handle are not ordinary tickets.
The end of life of Atlassian Data Center imposes a timetable on all its users: end of sales to new customers on 30 March 2026, last possible purchase or extension for existing customers on 30 March 2028, switch to read-only on 28 March 2029. The question is therefore not whether to move, but in what order and on what terms.
The real challenge.
A Cloud migration in a regulated sector is not a tooling question. The real issue is what you agree to let out of the building. Two questions were blocking every decision.
As long as the answer stays theoretical, no committee signs.
An Atlassian environment several years old carries configurations, histories and dependencies, some of which do not deserve the journey.
The real test of sovereignty is not going in with a supplier. It is getting out.
The BleuLemon setup.
We began with the inventory, not with the switchover timetable: the real scope of the projects, the configurations, the dependencies, the data within the sensitive perimeter. This stage has a name here, the Cloud Readiness study. It serves to separate what migrates, what is archived and what stops.
We then built a POC for anonymising sensitive data, on a limited and verifiable scope. A POC is not there to show that a technology exists: it is there to settle a precise question in front of the people who carry the risk. Does the data remain usable once anonymised, and does the method hold at the scale of the target scope? The POC was validated.
The audit and the POC feed a Cloud trajectory: scenarios, dependencies, switchover order, control points. What follows is committed with the client, step by step.
The three stages of the engagement.
| Stage | Purpose | Deliverable | Status |
|---|---|---|---|
| Audit | Existing Atlassian environment, scope of the sensitive data | Mapping and Cloud Readiness study | Completed |
| POC | Anonymisation of sensitive data | Proof of feasibility on a limited scope | Validated |
| Trajectory | Switchover scenarios, dependencies, timetable | Documented Cloud trajectory | Documented, commitment left to the client's decision |
Key takeaway. Migrations rarely fail on the technology. They fail on a regulatory question raised too late, when the timetable has already been announced and the budget already voted. Operational continuity cannot be decreed, it is prepared. Here it was prepared in order: the audit before the POC, the POC before the commitment, the commitment before the timetable.
BleuLemon, a French consultancy (Paris, Lyon) and Atlassian Platinum Solution Partner since 2008.
You are putting off a migration you know is inevitable, because a regulatory question has no verifiable answer yet.
Let's talk specifics.
Frequently asked questions
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 expertWhat is an anonymisation POC and what is it for?
It is a proof of concept on a limited scope, checking two things: that the data remains usable after anonymisation, and that the method holds at the scale of the target scope. Its value is in decision-making. It turns a committee debate of opinions into a verifiable result, before any budget commitment.
Where is the data hosted after an Atlassian Cloud migration?
The question is settled during scoping, product by product: hosting region, data concerned, subcontractors, retention period. We separate two subjects that are often confused. Legal sovereignty concerns the law applicable to the processing. Operational sovereignty concerns your ability to operate without your supplier.
Can you migrate in stages, project by project?
Yes, and it is the default approach in regulated environments. The audit sets the order: the projects with no sensitive data first, the constrained perimeters afterwards, once the method has been validated. This progression gives real control points, instead of a single switchover that no one can roll back.
Why talk about reversibility before even migrating?
Because reversibility is verified on the way out, not on the way in. It covers your data, your configurations, your attachments, your history, your rights, a usable format and workable timeframes. This is not an anti-supplier stance, it is business-continuity hygiene, and it is negotiated before signing.
How long does an Atlassian Cloud migration take?
It depends on the volume and on the Marketplace apps involved. The Atlassian FastShift programme brings a typical migration down from 12 to 16 months to 2 to 6 months, with eligibility from 1,000 users and a Cloud subscription. The Ascend programme provides resources, schedules and documentation.
What are the end-of-life deadlines for Atlassian Data Center?
Three dates structure the timetable. 30 March 2026: end of Data Center sales to new customers. 30 March 2028: last possible purchase or extension for existing customers. 28 March 2029: effective end of life and switch to read-only. Jira Align Data Center remains out of scope.
Going further: Atlassian Cloud migration·Aquarius·Atlassian licensing·Banking, Finance & Insurance·All case studies·The blog