In the second part of our ‘EU Sovereign Cloud’ series, we analysed in theory how European cloud providers compare to Azure in terms of features – but what is the reality? We undertook the ultimate practical test: a complete migration of a cloud-native application from Microsoft Azure to the IONOS Cloud. Containers, secrets, AI services – everything that makes up a modern architecture had to be ported. The process included surprising hurdles, creative workarounds and some unexpected insights. In this third part, we show what could be replicated directly, where there were gaps, and how to close them using re-architecture. Here's an honest account of our experience with concrete lessons learnt for anyone wishing to make the leap to the EU Sovereign Cloud.
Contents
We have chosen an AI assistant application to support invoicing, which is representative of modern cloud-native workloads. The application consists of three components: a chat UI, an MCP server for Docuware integration, and a backend job processor for asynchronous document processing. Users interact via chat with an AI assistant, which generates follow-up documents based on timesheets and other records. User actions trigger asynchronous jobs for document creation in the background. Technically, everything runs on Azure Container Apps; Azure Table Storage serves as a repository for asynchronous jobs; images are managed in the Azure Container Registry; and provisioning is carried out via Terraform in GitLab CI. Users log in via SSO using Microsoft Entra ID. Standard Azure services for logging, secret management and storage are also utilised.
A typical Azure-native architecture that utilises the entire service ecosystem – ideal for testing migration complexity!
Fig. 1: Application infrastructure in Azure with CI/CD stack and external components.
If you’re used to Azure, you’ll need to be prepared for a few changes with IONOS. As well as the look and feel of the UI, there are also differences in fundamental concepts – gaps in IAM & governance (no traditional technical users or fine-grained RBAC), conditional grouping of cloud resources, and services that are not available at all. The following two screenshots show the IONOS Datacenter web UI.
Fig. 2: IONOS Data Centre Designer web UI.
Once the account has been created with just a few clicks and by registering a credit card, you are taken directly to the central user interface, the IONOS Data Centre Designer (see Fig. 2).
Fig. 3: IONOS Data Centre Details web UI.
As with Azure Resource Groups, cloud resources can be grouped into ‘Data Centres’. The individual infrastructure components are selected using drag-and-drop (see Fig. 3).
The following table shows the mapping of the Azure services used in IONOS:
|
|
Azure |
IONOS |
Note |
|---|---|---|---|
|
Infrastructure as Code |
Azure Terraform Provider |
|
Not all resources can be provisioned (e.g. AI Model Hub) |
|
IaC pipeline authentication |
Microsoft Entra ID Service Principal |
|
Must be created manually in the IONOS UI |
|
Resource Organisation |
Azure Resource Group |
|
Grouping is only possible to a limited extent (e.g. storage is excluded) |
|
Container runtime |
Azure Container Apps |
|
Provisioning via Terraform |
|
Log Collection |
Azure Log Analytics Workspace |
|
|
|
Container Registry |
Azure Container Registry |
|
including CVE image scanning and retention policies |
|
Blob Storage |
Azure Storage Account – Container |
|
Access from CI/CD is via an access key |
|
Persistent Volume Claims |
Azure Storage Account – Azure File |
|
Provisioning in K8s takes place automatically via storage classes |
|
AI Model Service (LLM) |
Azure OpenAI |
|
|
|
Secret Management |
Azure Key Vault |
|
No native IONOS solution available → re-architecture required |
|
Job Repository |
Azure Storage Account – Azure Table |
|
No IONOS-native solution available → Re-architecture required |
|
Identity Provider (SSO) |
Microsoft Entra ID App Registration |
|
Not a typical identity provider; IONOS IAM is primarily used for access control to cloud resources, not for actual end-user management |
|
Service-level RBAC |
Azure Managed Identity |
|
No service-level RBAC; instead, token-based authentication against cloud services (Container Registry, Loki, Storage) |
IONOS does not offer native secret management – a critical gap for our application and a case for re-architecting. As our central secret store, we have opted for OpenBao, an open-source fork of HashiCorp Vault, implemented as a StatefulSet in Kubernetes. OpenBao implements the HashiCorp Vault API and can therefore be seamlessly integrated into Kubernetes as a standard SecretStore using the External Secrets Operator. IaC provisioning of secrets via Terraform is also possible using the Vault Terraform provider.
Table Storage is not available at IONOS – so we also had to find an alternative for the job repository. We opted for Redis as a simple key-value store, also deployed in Kubernetes using a PVC. Unfortunately, this step required modifications to the application code in several components, though the development effort remained within reasonable limits.
IONOS IAM is primarily designed for access control to cloud resources, not for genuine end-user management in the same way as a regular identity provider. One possible solution would have been to set up our own Keycloak deployment in Kubernetes as a separate identity provider. However, we did not pursue this option further, as our application relies on existing users in Microsoft Entra ID and federation with Azure would therefore still be necessary. We are therefore sticking with Microsoft Entra ID for SSO – a pragmatic approach that demonstrates that not every service necessarily needs to be migrated.
The target architecture shows a mix of direct service mappings and necessary re-architecture. Whilst standard services such as Managed Kubernetes, Container Registry and Object Storage are directly available, OpenBao had to replace the missing secret management, and Redis had to take over the job repository function. Microsoft Entra ID remains in place for SSO – the final solution is therefore a hybrid one.
Fig. 4: Application infrastructure in IONOS with CI/CD stack and external components.
Kubernetes is the ultimate gap-filler – and hybrid architectures are often the strategically wiser choice. Our key takeaways from the migration:
Object storage, container registries and managed Kubernetes represent the lowest common denominator amongst cloud providers
Service gaps can be bridged, but require significantly more engineering effort
Native cloud services significantly reduce complexity – their absence is immediately noticeable
Infrastructure-as-Code via Terraform works, but has provider-specific limitations
Kubernetes-native solutions often offer greater flexibility than managed services, but they also shift operational responsibility to the team
The UI/UX quality of the IONOS portal leaves room for improvement
Documentation and guides are crucial for successful implementations
Additional costs arise from the higher price of the EU cloud infrastructure itself and from extra development and operational costs for in-house gap-filler solutions
Not everything needs to be migrated – strategic hybrid approaches are often more practical
Do you have any questions or need assistance?
Are you currently facing the challenge of defining the optimal path for your business and securing your digital sovereignty? As an experienced partner, we can help you navigate this complexity, make the right decisions and successfully implement your bespoke cloud strategy. Please contact us or find out more about cloud transformation on our website.