Migrating from AWS to a European cloud

Migrating from AWS to a European cloud has become a strategic question for French companies. Data sovereignty, cost control, regulatory compliance, technological independence: the motivations are many. But a poorly prepared migration can turn a governance decision into a major operational risk.

The real question is not how to move your servers from AWS to a European hosting provider. It is how to stay in control of your information system, your data and your operations after the change of provider.

A successful migration rests on a measurable approach: analyse dependencies, define sovereignty requirements, test service compatibility, secure transfers and validate performance before any final cutover.

Here are the technical and methodological best practices for running this project, particularly in a French SME or mid-sized company (ETI).

1. Understand what migrating to a European cloud really means

The first trap is confusing data location, digital sovereignty and technological independence.

These three notions are related, but they are not equivalent.

Data location is not enough

Hosting a database in an AWS Region located in Paris or Frankfurt makes it possible to process and store data within the European Union. On its own, that does not answer every sovereignty question.

You also need to examine:

• The jurisdiction that applies to the provider and any legal obligations to grant access to data.
• The people and entities authorised to administer the infrastructure.
• Where support teams are located and the conditions under which they access environments.
• Control of encryption keys and identity mechanisms.
• Subcontractors, secondary data flows and transfer procedures.

The GDPR notably requires that processing of personal data, and any transfers outside the European Economic Area, be properly governed. Choosing a European hosting provider therefore does not exempt a company from analysing its processing activities, its contracts and its data flows.

The European Commission also published, in 2026, a cloud sovereignty framework based on 48 criteria spread across eight categories, including legal, operational and technological sovereignty and the supply chain.

Key takeaway: a European cloud must be assessed on verifiable guarantees, not merely on the address of its data centre.

Is AWS necessarily incompatible with European sovereignty?

No. The situation is more nuanced.

AWS announced the general availability of its European Sovereign Cloud in January 2026, with independent European infrastructure designed to meet heightened requirements for sovereignty and operational control.

A company can therefore compare several scenarios: staying on AWS in a European Region, using a sovereign cloud offering, migrating to an independent European provider, or spreading certain workloads across several environments.

The choice depends on legal requirements, the technical services needed, the budget and the level of autonomy sought.

Sovereignty is not a label. It is a set of properties that you must be able to demonstrate.

2. Audit the existing estate before moving a single workload

A cloud migration does not begin by creating virtual machines at a new provider. It begins with a precise map of the existing system.

This is the step that prevents service outages, unexpected costs and incompatibilities discovered too late.

Build a complete technical inventory

For each AWS application, identify at a minimum:

The inventory must be complemented by a map of the dependencies between applications.

An application may appear independent while relying on a Lambda function, an SQS queue, an IAM policy or a KMS encryption mechanism. Moving its server alone is not enough to make it operational.

AWS specifically recommends starting by collecting configurations, usage and dependencies before selecting a migration strategy.

Measure before you size

Do not automatically reproduce the capacity provisioned on AWS.

Collect several weeks of representative metrics, ideally covering activity peaks and business cycles:

• CPU, memory and storage actually consumed.
• Application and database latency.
• Network throughput and volumes of data transferred.
• Request rates, queues and processing times.
• Load variations and peak periods.

These measurements form a performance reference, or baseline.

Without this reference, it will be difficult to determine whether the new environment is truly equivalent, more expensive or less performant.

Operating rule: no critical workload should be migrated without an identified business owner, a map of its dependencies and measurable success criteria.

3. Choose the right migration strategy: the 7 Rs

Not every application should be migrated in the same way.

The AWS migration framework distinguishes seven strategies commonly called the "7 Rs": Retire, Retain, Rehost, Relocate, Repurchase, Replatform and Refactor.

For an SME, a progressive migration is often more realistic than a wholesale rewrite.

A monolithic web application running on EC2 may be a candidate for rehosting. An application that relies heavily on Lambda, DynamoDB and AWS events will probably require more redesign or service replacement.

The goal is not to modernise every application at all costs. It is to choose, for each workload, the level of transformation that meets business objectives and the budget.

4. Design a portable architecture without falling into the "cloud-agnostic" trap

Portability is one of the most important goals of a migration to a European cloud. But it is often misunderstood.

A portable architecture is not one that can be moved instantly to any provider. It is one whose dependencies are known, controlled and replaceable at an acceptable cost.

Favour open standards over uncontrolled proprietary dependencies

For new building blocks or components being modernised, favour wherever possible:

• OCI containers to package applications.
• Kubernetes when distributed orchestration is justified by real needs.
• PostgreSQL or other standard relational databases when the data model allows it.
• OpenTelemetry for collecting and transmitting traces, metrics and logs.
• Terraform or OpenTofu, with maintained modules and configurations adapted to each provider.
• Documented, versioned, provider-independent APIs where relevant.

These choices can reduce the cost of a future migration and make testing easier.

However, Kubernetes alone does not guarantee an application's portability. Persistent volumes, load balancers, secrets management, networking, security policies and managed services can all still create provider-specific dependencies.

Likewise, shared infrastructure as code does not make two providers technically identical. Resources, permissions and networking mechanisms must be adapted and validated.

Treat AWS managed services as architectural dependencies

Managed services deliver value: they reduce the operational burden and let teams focus on the product.

But some AWS services have no strictly compatible equivalent at a European provider.

Take three examples:

S3-compatible storage is not necessarily a transparent replacement for S3.

You need to test client libraries, multipart operations, lifecycle rules, permissions, performance and notification mechanisms.

For each proprietary service, document three things: its business function, the available alternatives and the estimated cost of replacing it.

Avoid over-engineering multicloud

Running several clouds at the same time can reduce certain dependencies, but it also increases operational complexity, the skills required, network costs and the attack surface.

An SME does not necessarily benefit from operating two active production environments.

A modular architecture, independent backups and a tested export procedure can provide a sufficient level of autonomy without imposing a permanent multicloud infrastructure.

The right goal is demonstrable reversibility, not a proliferation of platforms.

5. Secure the data: migration is a security project in its own right

Data transfer is often the most sensitive phase of a migration.

A database may contain personal data, confidential commercial information, authentication secrets or data subject to contractual obligations.

Security must be designed before the first transfer.

Encrypt data in transit and at rest

Transfers must use secure protocols, such as properly configured TLS, and private or restricted channels where appropriate for the architecture.

Stored data must be encrypted at rest, including backups and temporary copies.

It is essential to distinguish encryption from control of the keys.

An organisation can encrypt its data while depending on the provider to administer the keys. If sovereignty requirements call for stronger control, key management must be examined separately: ownership, administration, rotation, recovery, revocation and separation of roles.

Keys must never be exported or shared without a formal procedure.

Apply the principle of least privilege

The account or role used to migrate the data must have only the permissions strictly necessary.

In particular, you need to:

1. Create dedicated, temporary migration identities.
2. Restrict access to the resources and time windows required.
3. Separate administration, transfer and validation rights.
4. Log sensitive operations.
5. Revoke temporary access after the migration.

Multi-factor authentication, secret rotation and monitoring of privileged activity must be built into the setup.

ENISA's security recommendations for SMEs stress adapting controls to the level of risk and assessing the provider's guarantees. They are a useful starting point for formalising the security requirements of a cloud project.

Plan an independent backup before any cutover

A migration must never be treated as a backup.

Before any irreversible operation, verify that the data can be restored in an environment independent of the source system.

Best practices include:

• A consistent, verified backup copy.
• Backups protected against unauthorised deletion or alteration.
• Separate administrative credentials for backups.
• A real restore test, not just a check that the files exist.
• A procedure for retaining and deleting temporary copies.

The decisive test is simple: can the company restore its application and its data without depending on the provider it is leaving?

If the answer has not been demonstrated, the migration is not yet reversible.

6. Migrate databases without losing transactions

Migrating databases is generally more complex than a simple file transfer.

Data volume, continuous writes, integrity constraints and differences between engines can make a direct cutover risky.

Choose between cold migration and continuous replication

Two broad approaches are possible.

Cold migration: the application is stopped, a consistent copy is taken, and the data is restored at the new provider. This approach suits systems with an acceptable downtime window.

Migration with continuous replication: the initial data is copied, then changes are replicated as they occur until the cutover. This method reduces downtime but requires rigorous monitoring of replication lag and consistency.

In the case of a PostgreSQL database, for example, logical replication can make certain migration scenarios easier, provided you check versions, extensions, sequences, non-replicated objects and specific constraints.

A successful replication does not automatically mean the two environments are functionally identical.

Define a controlled cutover procedure

A database migration procedure must define in advance:

• When writes are frozen, or the final synchronisation mechanism.
• The acceptable level of replication lag.
• The data verification method.
• The person authorised to approve the cutover.
• The stop criteria and the conditions for rollback.

Checks must cover record counts, checksums where relevant, integrity constraints and representative business queries.

A simple comparison of database sizes is not enough.

Example: for an invoicing system, you need to verify not only the number of invoices, but also the amounts, the payment statuses, the relationships between invoices and customers, and the absence of duplicates.

Validation must focus on the business properties that guarantee the application remains correct after migration.

7. Prepare for business continuity and the rollback plan

A migration's success is not measured solely by the fact that the new server starts up.

It is measured by the company's ability to keep operating, meet its commitments and restore its service in the event of an incident.

Define two indicators before the project

The RTO (Recovery Time Objective) is the maximum acceptable downtime for a service.

The RPO (Recovery Point Objective) is the maximum amount of data the company is willing to lose, expressed as a length of time.

These objectives must be defined per application, according to business impact.

A non-critical internal application may tolerate several hours of downtime. A transactional platform may require much stricter objectives.

These requirements determine the choices of architecture, replication, backup and cutover.

Build a genuine rollback plan

The rollback plan must specify the conditions that trigger abandoning the migration, the responsibilities and the operations to perform.

In particular, it must answer the following questions:

• What happens if the new environment's performance is insufficient?
• How do you return to the old system if the data has already been modified?
• How do you avoid divergent writes between the two environments?
• Who authorises the rollback?
• How long will the AWS system remain available after the cutover?

The trickiest point is data divergence. As soon as the new platform accepts writes, a return to AWS may require reverse replication or a reconciliation procedure.

A rollback should therefore never be presented as a simple DNS change.

AWS structures its own migrations around assessment, preparation, then migration and modernisation phases. This progressive logic, applied with validation criteria and operational controls, remains relevant for a migration to another provider.

8. Calculate the real cost: the price of the server is only part of the equation

A migration to a European cloud is not automatically cheaper than running on AWS.

Comparing only the monthly price of a virtual machine gives an incomplete picture of the total cost of ownership (TCO).

A serious financial analysis must include at least five categories of cost.

The five components of migration cost

1. Infrastructure: compute, storage, databases, networking, backups, licences and support.
2. Data transfer: AWS egress fees, bandwidth, intermediate transfers, temporary storage and any import fees.
3. Technical transformation: adapting applications, replacing managed services, testing and development.
4. Human operations: training, administration, on-call duty, monitoring and upskilling of teams.
5. Transition and risk cost: temporary parallel running, possible outages, regulatory validation and maintaining the contingency plan.

The calculation must be carried out over a consistent period, for example three years, comparing several scenarios: staying on AWS, migrating to a European provider, and a hybrid architecture.

Cloud cost must be related to a relevant business unit: cost per transaction, per active user, per case processed or per volume of useful compute.

An infrastructure that is cheaper at nominal capacity can become more expensive if it demands more administration or does not provide the managed services required.

Conversely, a migration can be economically justified even if the infrastructure alone costs more, when the gains in data control, compliance or risk reduction are valued in the financial model.

The right financial decision rests on a documented TCO, not on a comparison of list prices.

9. Execute the migration in stages: the recommended method for an SME

To limit risk, an SME or mid-sized company should favour a migration in functional batches, with validation criteria defined before each stage.

Here is an operational sequence applicable to an AWS-to-European-cloud migration project.

Migration roadmap

1. Stage 1 — Assess and decide
   Inventory workloads, map dependencies, classify data and define sovereignty, security and performance requirements.
2. Stage 2 — Select the provider
   Compare available services, contractual guarantees, location, access mechanisms, costs and exit conditions.
3. Stage 3 — Build the landing zone
   Configure networking, identity, encryption, logging, backups, infrastructure as code and the deployment pipeline.
4. Stage 4 — Migrate a non-critical pilot
   Choose a representative application, test the transfer, measure performance, verify restoration and document the gaps.
5. Stage 5 — Industrialise in batches
   Reuse the validated procedures, automate deployments and migrate applications according to their criticality and dependencies.
6. Stage 6 — Cut over and stabilise
   Execute the cutover procedure, monitor business and technical indicators, validate the service, then progressively close down the AWS environment.

The pilot is a decisive stage. It must be representative enough to reveal technical difficulties, without immediately exposing a critical activity.

It must produce reusable deliverables: migration scripts, architecture documentation, test results, a rollback procedure and an updated financial estimate.

The six pillars of the AWS Well-Architected Framework — operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability — also provide a structured grid for assessing architectures before and after migration.

10. The mistakes that most often jeopardise a cloud migration

Some mistakes can be avoided as early as the design phase.

The lesson is simple: a migration must not be driven solely by a transfer schedule. It must be driven by evidence that things work.

11. Conclusion: a successful migration is measured by the autonomy it creates

Migrating from AWS to a European cloud can serve important objectives of sovereignty, data governance, cost control and resilience.

But changing provider does not, by itself, guarantee security, compliance or technological independence.

Companies preparing for this transition must start by knowing their system precisely, defining their requirements, assessing proprietary dependencies and building a migration strategy adapted to each application.

The best protection against a risky migration is a documented architecture, reproducible tests, clear responsibilities and a genuinely verified exit procedure.

Digital sovereignty is not decreed at the moment a cloud contract is signed. It is built into the architecture, verified in operations and demonstrated by the ability to take back control of your system.

For French SMEs, this approach does not necessarily require a complete overhaul of the infrastructure. Above all, it requires a rigorous method, explicit technical trade-offs and a long-term vision.

That is precisely what turns a cloud migration into a genuine project of technological control.

12. Frequently asked questions about migrating from AWS to a European cloud

Can an AWS application be migrated to a European cloud without rewriting it?

Yes, in some cases. An application that relies mainly on virtual machines, standard databases and portable components can be moved with limited adaptations. Applications that depend heavily on proprietary AWS services generally require additional changes.

How long does a migration from AWS to a European cloud take?

The duration depends on the number of applications, data volumes, technical dependencies, availability requirements and the resources committed. A limited pilot can be run before a broader programme, but there is no reliable universal duration without a prior audit.

Does a European hosting provider automatically guarantee GDPR compliance?

No. Compliance depends in particular on the processing activities, contractual responsibilities, access, security measures, subcontractors and data transfers. The choice of provider is one component of compliance, not an overall guarantee.

Does Kubernetes make it possible to avoid vendor lock-in?

Kubernetes makes certain containerised applications more portable. It does not remove dependencies on storage, networking, identity, managed services or the operational tooling specific to each provider.

Do you need to leave AWS completely to gain sovereignty?

Not necessarily. Depending on regulatory and business constraints, a hybrid approach, a targeted migration or keeping certain workloads on AWS may be considered. The decision must be based on risks, control requirements and total cost.