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.

Key considerations for an HDS migration

Five recurring pitfalls deserve particular attention. Each one should prompt a question to your future hosting provider.

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.

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.

tl;dr: On March 21th 2022 the Cellar C1 cluster will reach its end of life. So we ask you to perform a migration to a newer cluster Cellar, which will also improve performance. The C1 cluster did not accept new add-ons since the 20th January 2019.

In fact, data need to be migrated from this old add-on to a new Cellar add-on. Newly created Cellar C2 add-ons come with various improvements :

• A better S3 protocol support (including the AWS V4 signature)
• Improved upload and download performances (x3 for upload, x2 for download)
• Improved resilience and availability of your data (Data is now replicated across two datacenters more than 20km apart)

How to migrate my data?

We can help you to migrate your data by syncing it directly on our side. To do that, reach the support and include in your message source and destination add-ons, including the buckets to migrate. The support team is here to help.

If you wish to migrate on your side, or at least keep your buckets synchronized, we built a simple tool to help you: Cellar migration tool.
You can run this tool as many times as you need. It will only synchronize objects that are different between the source and the destination buckets.
If you do not feel comfortable using it, you can also use the s3cmd sync command from the s3cmd tool.

If your application handle it, we encourage you to upload new objects as soon as possible to the new bucket. Then when you need to query that object, your application can query both buckets (old and new) to get it. You can also store the complete URL to make this easier. This should help you transition from one bucket to another without downtime.

Please note that we can't make sure that the buckets names you use will be available on the destination cluster. If you have a name conflict, please contact us and we will work something out.

A few days before the deadline, we will have short service brown-outs to remind customers that the service is going to be shut down. Those brown-outs will be announced on our status page a few days before. Make sure to subscribe to Status Updates to receive a notification.

What will happen if I can't do the migration?

If you can't do the migration or have any questions about it, we strongly recommend that you contact our support team via the console.
Before shutting down the cluster, we will backup your data and keep it for 6 months. Our support team will be able to provide you a download link or re-inject the data in a new bucket if you wish to recover it.

I am an existing Nodejitsu customer, how to proceed?

• the NodeJs articles in our documentation
• email support: support@clever-cloud.com

• Zero Downtime Deployments
• Build cache for instant re-deployments
• HTTP/HTTPS Routing
• Custom Domain Names
• Application SSL
• Sticky Sessions
• Application Clustering
• Environment variables
• European and American regions

• Deploying Play Framework 2 apps on Clever Cloud
• Using Java Maven on Clever Cloud
• Deploying WAR/EAR projects

• Zero Downtime Deployments
• HTTP/HTTPS Routing
• Custom Domain Names
• Application SSL
• Sticky Sessions
• Application Clustering
• Environment variables