The remaining questions are when such an operation becomes necessary, how it is carried out, and which pitfalls should be anticipated.
What is an HDS migration?
An HDS migration is more than a simple infrastructure change: it involves transferring personal healthcare data whose hosting is regulated by law. The objective can be summed up in a single sentence: change hosting providers without leaving the compliance framework, either during or after the migration.
HDS certification itself remains the responsibility of the hosting provider under the HDS framework and its six regulated activities. Migrating does not invalidate this compliance; the objective is to preserve it throughout the transition from one hosting environment to another.
When should you consider an HDS migration?
Three situations justify switching the hosting environment for healthcare data.
Hosting that is not HDS certified
In France, entrusting healthcare data to a hosting provider requires that provider to hold HDS certification (Article L.1111-8 of the French Public Health Code). An e-health application deployed on non-certified infrastructure therefore falls outside this regulatory framework, regardless of its technical quality. Migrating to a certified hosting provider addresses the hosting requirement, although it does not by itself fulfil the publisher’s other obligations, whether application-related or under the GDPR.
Hosting that is not sovereign or is subject to extraterritorial legislation
Certification and legal sovereignty are not the same thing. A hosting provider may be HDS certified while still being subject to non-European legislation that could require the disclosure of data, such as the Cloud Act or FISA. For the most sensitive healthcare data, the CNIL recommends enhanced protection against access requests from third-country authorities, including hosting operated exclusively under European law. The distinction between HDS compliance and sovereignty deserves separate consideration; in the context of a migration, it mainly becomes a hosting provider selection criterion.
Operational overhead on self-managed infrastructure
Infrastructure may be compliant while still being managed in-house, typically on bare metal. In this case, internal teams remain responsible for server configuration, monitoring, upgrades, and reversibility. As the platform grows, this operational burden becomes increasingly significant. It often leads software vendors that are already HDS compliant to adopt a managed platform, reducing operational workload without compromising compliance.
How does an HDS migration work, step by step?
The project follows five phases, from initial assessment to final compliance verification.
Scoping and preliminary assessment
Before any transfer takes place, the scope must be clearly defined: which healthcare data is involved, which applications process it, and where the backups are located. This stage determines which HDS framework activities are actually involved and which data residency requirements must be met, including backup copies.
HDS contractual agreement
Hosting healthcare data requires a dedicated agreement between the customer and the hosting provider. This is a requirement of the HDS framework, not a commercial formality: the agreement defines the allocation of responsibilities and must be in place before the production environment goes live.
Data transfer and synchronization
This is the core operation: copying and synchronizing the data, deploying the applications, and restoring scheduled tasks and monitoring. Encryption at rest is enabled when databases and storage volumes are created. Depending on the source infrastructure, this phase may also require adapting file formats inherited from third-party storage systems.
DNS switch: the only possible interruption
As long as the legacy and the new platforms coexist, the service continues to run on the former. The DNS switch to the new hosting environment is the only point at which an interruption may occur. When properly prepared, it remains imperceptible to users.
Post-migration compliance verification
The migration does not end with the DNS switch. The final step is to verify that the certified scope covers the entire deployed environment, that backups comply with the same data residency requirements as the primary data, and that reversibility remains fully guaranteed.
Key considerations for an HDS migration
Five recurring pitfalls deserve particular attention. Each one should prompt a question to your future hosting provider.
-
01
01 Partially certified scope
Some offerings cover only part of the six activities defined by the HDS framework, often limited to the infrastructure layers. Partial coverage leaves parts of the environment outside the compliance scope and under the customer’s responsibility.
0202 Backup location
Hosting primary data in France while storing backups elsewhere merely shifts the risk instead of eliminating it. Backup copies must comply with the same requirements as the original data.
0303 Remote administration from a third country
Even when data is stored in France, it remains exposed if the platform is administered from a country subject to non-European legislation. In such cases, the HDS framework requires the hosting provider to inform its customer.
0404 Reversibility
The inability to recover all data in a usable format creates vendor lock-in, which may prevent future compliance efforts.
0505 Division of responsibilities
Using an HDS-certified hosting provider does not make the customer HDS certified. Responsibility for application compliance and GDPR compliance remains with the software publisher
How do you choose an HDS hosting provider for your migration?
Five criteria make the difference:
- Certification covering all six activities defined by the HDS framework, not just the infrastructure layer.
- A valid certificate issued by an accredited certification body.
- Genuine sovereignty: headquarters and ownership based in France, no subsidiary subject to non-European law, and hosting infrastructure located in France.
- A fully managed platform that takes care of encryption, monitoring, backups, and updates instead of leaving these responsibilities to the customer.
- Documented reversibility, ensuring an exit strategy without technical lock-in.
The last criterion deserves particular attention: a platform that operates an HDS cloud end to end relieves customers of the operational layers where most compliance gaps tend to arise.
Checklist, migration steps, common mistakes, and hosting provider selection criteria. Find all of these in our Practical Guide to HDS Migration.
Case study: the Madietenligne migration
Clever Cloud supports several e-health providers. The migration of Madietenligne, a platform dedicated to dietitians, provides a documented example: it moved from self-managed bare-metal infrastructure to Clever Cloud’s sovereign PaaS while remaining within the HDS framework. This case illustrates a migration driven by the need to reduce operational overhead rather than to move from a non-compliant to a compliant environment: the HDS framework was already being met before the migration.
Key highlights:
- Test and production environments migrated in less than fifteen days.
- 500 GB of data transferred and synchronized.
- Platform used by more than 2,500 dietitians.
- Zero-downtime deployments, with support responding within the same business day.
- HDS compliance maintained, encryption at rest enabled, and migration away from Azure for file storage, removing a dependency on a provider subject to U.S. law.
Key takeaways from an HDS migration
A well-executed HDS migration answers three questions, in order: why migrate, how to migrate, and how to verify compliance. The process is manageable, service interruption is limited to the DNS switch, and compliance can be verified at every stage.
To assess your current situation or prepare your migration project,
FAQ
How long does an HDS migration take?
The duration depends on the data volume, the architecture, and the number of environments involved. As a reference point, one documented project covering both test and production environments was completed in less than fifteen days. This figure applies only to that specific case and should not be taken as representative of every migration.
Does an HDS migration cause service downtime?
As long as the legacy and the new hosting environments coexist, the service remains available. The only possible interruption occurs during the DNS switch; when properly prepared, it is imperceptible to users.
Is a new contract required for an HDS migration?
Yes. Hosting healthcare data requires a dedicated agreement with the hosting provider under the HDS framework. It must be signed before the production environment goes live.
After the migration, what remains my responsibility to stay HDS compliant?
HDS certification remains the responsibility of the hosting provider. The software publisher remains responsible for application compliance and GDPR compliance. The migration brings the hosting component into compliance, but it does not cover all regulatory obligations.
Can I migrate from a non-sovereign hosting provider such as Azure or AWS?
Yes. One purpose of an HDS migration may be to remove a dependency on a hosting provider subject to non-European legislation, for example by moving away from file storage operated by a non-European provider.
Blog
À lire également
HDS migration: migrate your healthcare data with no perceptible downtime
An HDS migration consists of transferring an application and its healthcare data from one hosting provider to another while maintaining the required certification and service continuity. When properly planned and executed, the perceived interruption can be reduced to a simple DNS switch. For example, when Madietenligne, a provider of an e-health solution for dietitians, migrated to Clever Cloud, its test and production environments were moved in less than fifteen days, covering 500 GB of data, with no downtime perceived by users.Gravitee and Clever Cloud Announce Strategic Partnership for European AI Sovereignty
Gravitee and Clever Cloud Provide an Open-Source, Deploy-Anywhere Control Plane Ensuring European AI Runs Strictly on Your Terms.Magnetar: a Rust Apache Pulsar client built for deterministic simulation
Some of the most interesting reliability work in distributed systems starts with a simple idea: if a system can fail in production because of time, scheduling, networking, or unlucky interleavings, then those forces should be brought into tests under control.