Moving from Microsoft Azure to an EU-owned cloud

Moving from Microsoft Azure to an EU-owned cloud requires rebuilding your compute and network configurations as code, replicating relational databases in real time, and shifting storage calls from Azure’s proprietary APIs to standard S3-compatible endpoints. For most European software companies running Linux virtual machines, Kubernetes, PostgreSQL, and object storage, the migration takes a few weeks of preparation and a cutover pause of a few minutes. The main technical hurdles are decoupling Microsoft Entra ID from infrastructure access, swapping out the Azure Blob Storage SDK, and replacing proprietary services like Azure Service Bus or Cosmos DB with open-source equivalents.

Key takeaways

Standard workloads move cleanly: Linux VMs, Azure Kubernetes Service (AKS), and Azure Database for PostgreSQL or MySQL map directly to EU providers like UpCloud, Scaleway, OVHcloud, and STACKIT.
Object storage requires a code change: Unlike AWS and most European clouds that use the S3 API, Azure Blob Storage uses its own REST interface. You will need to update your application’s storage client or use an S3-compatible abstraction library.
Egress fees are disappearing: Under Article 29 of the EU Data Act, cloud providers can charge no more than their direct cost for switching egress until January 12, 2027, when switching fees are banned outright. Microsoft also offers a free egress credit program when you close your Azure subscriptions.
Microsoft 365 can stay where it is: Moving production servers and customer databases to a European cloud does not mean you have to abandon Entra ID for employee single sign-on or Microsoft 365 for email.
Rollback keeps the cutover safe: By using logical database replication, you can sync changes back to Azure after the DNS switch, preserving a clean fallback option while your team verifies the new environment.

Why European companies are reconsidering Azure

Many European organizations adopted Azure because they already used Windows Server, Active Directory, or Office 365. Over time, however, the infrastructure footprint often grows into a standard Linux and open-source stack that does not depend on Microsoft software, while the bill and compliance questions continue to grow.

Three practical reasons drive teams to move production workloads from Azure to an EU-owned cloud:

Jurisdiction and sovereignty: Even when you select Azure regions in Frankfurt, Amsterdam, or Dublin, Microsoft Corporation remains a US-headquartered company subject to US extraterritorial laws such as the CLOUD Act. For companies serving public sector clients, healthcare, or regulated financial institutions, hosting on an EU-headquartered provider removes this legal conflict.
Exit strategy mandates: The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied since January 17, 2025, requires financial entities and their critical ICT providers to maintain tested exit strategies and avoid concentration risk with hyperscalers.
Predictable billing: Azure pricing involves complex tiers of vCPUs, Storage Transaction Units, Virtual Network peering fees, NAT Gateway processing charges, and outbound bandwidth tiers. European providers generally bundle network traffic or charge flat monthly rates for compute and storage.

Mapping your Azure stack to EU cloud equivalents

Before moving any data, you need an accurate inventory of every resource group in your Azure subscriptions. Most architectures fall into three categories: components that translate directly, components that need minor code or configuration adjustments, and proprietary services that require architectural changes.

Azure Service	Open Standard / Protocol	EU Cloud Equivalents (UpCloud, Scaleway, OVHcloud, Hetzner, IONOS, STACKIT)	Migration Complexity
Azure Virtual Machines	x86 / ARM Linux VMs	Cloud Servers / Instances on all EU providers	Low: Redeploy via Terraform and CI/CD.
Azure Kubernetes Service (AKS)	Certified Kubernetes	Managed Kubernetes on UpCloud, Scaleway, OVHcloud, IONOS, STACKIT; self-managed on Hetzner	Low: Standard manifests and Helm charts port over; update storage and ingress annotations.
Azure Database for PostgreSQL / MySQL	PostgreSQL / MySQL wire protocols	Managed Databases on UpCloud, Scaleway, OVHcloud, IONOS, STACKIT; self-hosted on Hetzner	Low: Live sync via native logical replication.
Azure Cache for Redis	Redis / Valkey protocol	Managed Redis/Valkey on UpCloud, Scaleway, OVHcloud; container or VM elsewhere	Low: Point app to new endpoint; warm up cache or sync via replication.
Azure Blob Storage	Proprietary Azure REST API	S3-compatible Object Storage on all listed EU providers	Medium: Data copies via `rclone`; app code must swap Azure SDK for S3 SDK.
Azure Application Gateway / Load Balancer	TCP / HTTP / TLS	Managed Load Balancers on all listed EU providers	Low: Rebuild routing rules and TLS certificates in Terraform.
Azure Functions	Proprietary triggers / C# / Node / Python	Scaleway Serverless Functions, or containerize onto Kubernetes / VMs	Medium: HTTP functions wrap easily in containers; event triggers need rewiring.
Azure Service Bus / Event Hubs	AMQP 1.0 / Kafka API	RabbitMQ or Kafka (Managed on OVHcloud/Scaleway, or self-hosted)	Medium: If using AMQP or Kafka clients, change connection strings; SDK users must refactor.
Azure SQL Database (MSSQL)	T-SQL / Tabular Data Stream	Linux VM running SQL Server, or schema migration to PostgreSQL	High: Licensing changes or application query rewrites required.
Azure Cosmos DB	Proprietary APIs (NoSQL, Mongo, Cassandra)	Managed MongoDB (OVHcloud, Scaleway) or self-hosted Cassandra / PostgreSQL JSONB	High: Requires careful data modeling and application testing.

Note on Hetzner: Hetzner provides cost-effective virtual and dedicated servers, load balancers, networks, and S3-compatible object storage, but it does not offer managed databases or managed Kubernetes. When migrating to Hetzner, those services must be deployed and maintained on virtual machines.

Four Azure-specific friction points (and how to handle them)

Moving off Azure is slightly different from moving off AWS or Google Cloud because of how Microsoft couples identity, storage, and enterprise software.

1. Replacing the Azure Blob Storage SDK with S3

Every major European cloud provider builds its object storage around the Amazon S3 API standard. Azure Blob Storage uses a different structure (Storage Accounts, Containers, and Blobs) and its own SDK (@azure/storage-blob in Node.js, azure-storage-blob in Python, Azure.Storage.Blobs in .NET).

To migrate, you must update the storage layer in your application code to use a standard S3 client library (such as boto3 for Python or the AWS SDK for .NET configured with a custom endpoint URL). If your application generates Shared Access Signature (SAS) URLs so users can upload or download files directly, you will replace that logic with S3 presigned URLs. They work the same way and take only a few lines of code, but you must account for this change in your sprint planning.

For the files themselves, open-source tools like rclone talk natively to both Azure Blob Storage and S3-compatible targets, verifying cryptographic checksums on every transferred file.

2. Untangling Microsoft Entra ID (formerly Azure AD)

Teams often worry that leaving Azure means rebuilding their company’s entire identity setup. You need to separate two distinct uses of Entra ID:

Employee and customer authentication: If your back-office tools or web apps use Entra ID via OpenID Connect (OIDC) or SAML, nothing needs to change. OIDC works over the public internet regardless of where your servers live.
Infrastructure Managed Identities: If your Azure VMs or AKS pods use Azure Managed Identities to authenticate to databases or storage without passwords, you will need to replace this mechanism. On an EU cloud, you typically move to Kubernetes secrets, HashiCorp Vault, database username/password authentication over private networks, or scoped S3 access keys.

3. Dealing with .NET, Windows, and SQL Server

If your company writes applications in modern .NET (.NET 6, 8, or newer), your code runs natively on Linux containers and Linux VMs. Moving a modern C# application to a European Kubernetes cluster or Linux server is no different from moving a Go, Node.js, or Python app.

However, if you rely on legacy .NET Framework (4.8 and older) on Windows Server, or if your application depends heavily on Azure SQL Database (Microsoft SQL Server), the migration requires more planning. While some European providers offer Windows Server licensing, many engineering teams use an infrastructure move as the moment to migrate schemas from SQL Server to PostgreSQL using tools like pgloader, eliminating Microsoft licensing fees altogether.

4. Rebuilding ARM or Bicep into Terraform

If your infrastructure is defined using Azure Resource Manager (ARM) templates or Bicep, those files cannot be reused on another cloud. Even if you already use Terraform or OpenTofu, the azurerm provider blocks must be rewritten using the provider plugin of your chosen European cloud (such as upcloud, scaleway, or ovh). Treating the migration as a clean rebuild in Terraform gives you an auditable, documented environment from day one.

Egress fees and your legal rights under the EU Data Act

Historically, cloud providers charged steep outbound data transfer fees (around $0.08 to $0.087 per GB on Azure after the first 100 GB per month, as of 2026) when you copied terabytes of backups and object storage over the internet.

In the European Union, Regulation (EU) 2023/2854 (the EU Data Act) changes the rules for switching data processing services:

Transitional cap (until January 12, 2027): Providers may charge switching fees, including data egress fees incurred while moving to another provider, at no more than the direct cost incurred to perform the switch.
Full ban (from January 12, 2027): Switching charges and data egress fees for switching between cloud providers are banned completely for EU customers.

Following the introduction of the Data Act, Microsoft introduced two policies you can use today (check Microsoft’s official documentation and bandwidth pricing pages for current terms as of 2026):

Free egress when leaving Azure: Microsoft offers credits to cover internet data egress over 100 GB/month when you are migrating all data off Azure to another cloud provider. To qualify, you must open an Azure Support ticket before starting the transfer, follow their instructions, and cancel the associated Azure subscriptions once the migration is complete.
At-cost egress for parallel multi-cloud use: For EEA, EFTA, and UK customers running workloads across Azure and another provider in parallel, Azure offers reduced, at-cost data transfer rates upon submitting a support request with the destination provider’s Autonomous System Number (ASN).

Step-by-step migration checklist

A reliable cloud migration avoids copying messy, years-old virtual disks. Instead, rebuild the infrastructure cleanly, stream the data across, and deploy fresh application artifacts from your existing pipeline.

1. Audit and right-size: Export your Azure Cost Management billing data and list every active resource. Identify idle VMs, unattached Managed Disks, and oversized databases so you only pay for what you actually use on the new cloud.
2. Refactor storage calls: Update application code that speaks directly to the Azure Blob Storage API so it supports standard S3 endpoints and presigned URLs.
3. Write the target infrastructure as code: Define your new private networks, firewall rules, load balancers, Kubernetes clusters, and managed database instances in Terraform on your target EU cloud.
4. Establish database replication: Set up a secure VPN or WireGuard tunnel between your Azure Virtual Network and the new EU cloud private network. Configure PostgreSQL logical replication (CREATE PUBLICATION on Azure, CREATE SUBSCRIPTION on the target) or MySQL binlog replication so the new database catches up and stays in live sync.
5. Clone object storage: Run rclone sync from a worker node to copy all containers from Azure Blob Storage into your new S3 buckets. Re-run periodically to sync newly uploaded files.
6. Point CI/CD to the new environment: Update your GitHub Actions, GitLab CI, or Azure DevOps pipelines to deploy your containers or application binaries to the new EU servers. Test the staging environment thoroughly.
7. Execute the cutover: Lower your DNS TTLs 24 hours in advance. During a scheduled low-traffic window, put the application in brief maintenance mode (pausing writes), run a final incremental rclone pass, verify that database replication lag is zero, promote the EU database to primary, and update your DNS records.
8. Maintain reverse replication before cleanup: Configure replication from your new EU primary database back to the old Azure database for 30 days. Once you are confident in the new setup, cancel the Azure subscriptions and claim any applicable egress credits.

Frequently asked questions

Can we keep using GitHub Actions or Azure DevOps if we move our servers to an EU cloud?

Yes. Your CI/CD runners only need network access or API credentials to deploy to your new servers or Kubernetes cluster. Many European teams keep their source code and pipelines on GitHub or Azure DevOps while moving production compute and customer databases to an EU provider.

How much downtime is required to switch from Azure Database for PostgreSQL?

Because PostgreSQL logical replication syncs data continuously in the background while your application stays online, you do not have to wait for a multi-hour dump and restore during cutover. Once replication lag is under a few seconds, you only need a short planned write pause—typically a few minutes—to let the last transactions flush, verify data consistency, and switch your application traffic.

What if we use Azure Kubernetes Service (AKS)?

Kubernetes is one of the easiest workloads to move. Standard Deployment, Service, and Ingress manifests work across any certified Kubernetes cluster. You will mainly need to change Azure-specific storage class names (for example, changing managed-csi to the CSI driver of UpCloud, Scaleway, or OVHcloud) and replace any Azure Key Vault CSI drivers with standard Kubernetes secrets or external secret operators.

Is Microsoft’s EU Data Boundary enough for European sovereignty?

Microsoft’s EU Data Boundary stores and processes customer data within European data centers, which helps with data residency requirements. However, data residency is different from legal jurisdiction. Because Microsoft is a US company, European residency does not insulate infrastructure from US legal jurisdiction in the same way that contracting with a wholly EU-owned cloud provider does.

How MoveInfra can help

If your team wants to move off Azure without pulling engineers away from product work for months, MoveInfra handles the migration end-to-end for a fixed price. We analyze your current Azure setup, rebuild your environment as clean Terraform code on an EU-owned cloud (such as UpCloud, Scaleway, OVHcloud, or Hetzner), keep your databases and object storage in live sync, and help your team switch over with a 30-day reverse-replication rollback window. Upload your cloud bill at moveinfra.eu for a free assessment of what can move automatically and what your new monthly infrastructure cost will look like.