Find the right AI use cases before investing in development.
Connect AI to your existing systems and workflows.
Build autonomous AI agents that automate complex tasks.
Design and develop AI solutions tailored to your business.
Build secure, scalable AI systems for enterprise environments.
Legacy software modernization →
Upgrade outdated systems for better performance, security, and scalability.
Make informed technology decisions before investing in development.
Validate your product idea with user and business insights.
Define the right scope to launch faster and reduce risk.
Confirm your idea is technically viable before you build.
Capabilities
Want to start a software project with us?
Book a time with our technology experts →
We brought young developers together to explore the future of AI agents. More editions are coming soon.
DENot every service takes the same effort to move, and not everything has to move at once. Tick the services you run and get your portability profile, with a European option for each one.
2Which services do you use?
We've ticked a typical setup to start with. Change it to match yours, then check where each service lands.
Your portability profile
Category 1: Ready to move directly
Widely supported technology. Moves with proven methods and little disruption.
Category 2: Move with adjustments
European equivalents exist. Some changes needed, but the effort is predictable.
Category 3: Deeply embedded
Tied closely to one provider. Needs a deliberate call: replace, rebuild or leave it where it is.
Not a dealbreaker. Every one of these services can be replaced or rebuilt. We help you plan the move step by step, so nothing here should stop you from changing providers.
Indicative, based on typical environments. Your configuration decides the real effort, and the Cloud Analysis assesses every service individually. Mappings last reviewed 20 October 2026. We don't earn commissions from any provider named here.
| Service | Category | European option | What changes |
|---|---|---|---|
| Amazon Web Services | |||
| Amazon EC2 | 1 Ready to move directly | Compute instances (STACKIT, IONOS, Open Telekom Cloud, Exoscale) | Images and configurations move with standard tools. A good moment to right-size. |
| Amazon EKS | 1 Ready to move directly | Managed Kubernetes (STACKIT SKE, Open Telekom Cloud CCE, Exoscale SKS) | Manifests and Helm charts move largely as they are. Provider-specific add-ons (load balancers, identity hooks) are swapped. |
| Amazon ECS and Fargate | 2 Move with adjustments | Managed Kubernetes | The containers stay the same. Task definitions are rewritten as Kubernetes deployments. |
| AWS Lambda | 2 Move with adjustments | Functions on Kubernetes (Knative, OpenFaaS) or plain containers | The code moves easily. Rebuilding the triggers and integrations takes most of the effort. |
| AWS Elastic Beanstalk | 2 Move with adjustments | Containers on managed Kubernetes | Each app is containerized once. The platform configuration is rebuilt. |
| Amazon S3 | 1 Ready to move directly | S3-compatible object storage (STACKIT, IONOS, Open Telekom Cloud, Hetzner) | Same API, so applications barely change. The one-time transfer is planned upfront. |
| Amazon EBS and EFS | 1 Ready to move directly | Block and file storage at the target provider | Moves together with the servers that use it. |
| Amazon RDS (PostgreSQL, MySQL, MariaDB) | 1 Ready to move directly | Managed PostgreSQL, MySQL or MariaDB (STACKIT, IONOS, Exoscale) | Standard engines with standard migration tools. Replication keeps the cutover window short. |
| Amazon Aurora | 2 Move with adjustments | Managed PostgreSQL or MySQL | Engine-compatible, but Aurora-only features such as Serverless or Global Database need a replacement plan. |
| Amazon ElastiCache | 1 Ready to move directly | Managed Valkey or Redis (Exoscale, OVHcloud) | Same protocol, so this is usually a configuration change. |
| Amazon DocumentDB | 2 Move with adjustments | Managed MongoDB (STACKIT, IONOS, OVHcloud) | MongoDB-compatible API, but some behavior differs, so queries and indexes are checked. |
| Amazon DynamoDB | 3 Deeply embedded | Data model redesigned for PostgreSQL, MongoDB or similar | Proprietary to AWS. Usually the most involved part of the move, and it removes one of the biggest sources of lock-in. |
| Amazon SQS and SNS | 2 Move with adjustments | RabbitMQ, Apache Kafka or NATS | Messaging patterns map well. Client code and permissions change. |
| Amazon EventBridge | 2 Move with adjustments | Event bus on Apache Kafka or NATS | Event rules and routing are rebuilt. |
| Amazon Kinesis | 2 Move with adjustments | Apache Kafka | Kafka is the open standard for streaming. Producers and consumers are adapted. |
| Amazon API Gateway | 2 Move with adjustments | Open API gateway (Kong, Traefik) or Kubernetes ingress | Routes move over. Authorizers and usage plans are rebuilt. |
| AWS Step Functions | 3 Deeply embedded | Workflow engine such as Temporal or Argo Workflows | State machines are written in an AWS-only language and get rebuilt. Decide workflow by workflow. |
| AWS AppSync | 3 Deeply embedded | GraphQL server such as Hasura or Apollo | Resolvers are tied to AWS services and are rewritten. |
| Amazon Cognito | 2 Move with adjustments | Provider-independent identity platform (Keycloak, Zitadel) | Both run in parallel. Cognito can't export password hashes, so users move over gradually as they sign in. |
| AWS IAM | 2 Move with adjustments | Access management of the target platform, managed as code | Policies are rewritten for the new platform, ideally as code in Terraform. |
| AWS KMS and Secrets Manager | 2 Move with adjustments | Provider KMS or OpenBao, with keys only you control | Secrets move easily. KMS keys can't be exported, so data is re-encrypted under new keys. |
| Amazon Redshift | 2 Move with adjustments | ClickHouse or a PostgreSQL-based warehouse | Most SQL carries over. Loading pipelines are adapted. |
| AWS Glue and Amazon Athena | 2 Move with adjustments | Apache Spark and Trino | Open engines. Jobs and the data catalog are rebuilt around them. |
| Amazon SageMaker | 2 Move with adjustments | Open MLOps tooling (MLflow, Kubeflow) on European GPUs | Models usually stay the same. Training, deployment and monitoring are rebuilt around them. |
| Amazon Bedrock | 2 Move with adjustments | Sovereign AI platform with open or European models | Prompts and application logic stay. The model endpoint changes. |
| Amazon CloudFront | 1 Ready to move directly | European CDN | Cache and routing rules are recreated. The cutover itself is a DNS change. |
| Amazon Route 53 | 1 Ready to move directly | DNS at a European provider | Zones export as standard zone files. Health-check routing needs a replacement. |
| Microsoft Azure | |||
| Azure Virtual Machines | 1 Ready to move directly | Compute instances (STACKIT, IONOS, Open Telekom Cloud, plusserver) | Images and configurations move with standard tools. A good moment to right-size. |
| Azure Kubernetes Service (AKS) | 1 Ready to move directly | Managed Kubernetes (STACKIT SKE, Open Telekom Cloud CCE, plusserver) | Manifests and Helm charts move largely as they are. Provider-specific add-ons (load balancers, identity hooks) are swapped. |
| Azure Container Apps | 2 Move with adjustments | Managed Kubernetes with KEDA and Dapr | Built on open components that run on any Kubernetes. The app configuration is rewritten. |
| Azure App Service | 2 Move with adjustments | Containers on managed Kubernetes, or managed web hosting such as Mittwald | Each app is containerized once. Deployment slots and settings are rebuilt. |
| Azure Functions | 2 Move with adjustments | Functions on Kubernetes (Knative, KEDA) or plain containers | The code moves easily. Triggers, bindings and Durable Functions take most of the effort. |
| Azure Blob Storage | 2 Move with adjustments | S3-compatible object storage (STACKIT, IONOS, Open Telekom Cloud) | Moving the data is simple. Code that calls the Blob API switches to the S3 API, usually a contained change. |
| Azure Managed Disks and Azure Files | 1 Ready to move directly | Block and file storage at the target provider | Moves together with the servers that use it. |
| Azure SQL Database | 1 Ready to move directly | Managed SQL Server (STACKIT, IONOS), or PostgreSQL | Managed SQL Server is available in Europe, so check licensing. Moving to PostgreSQL is a bigger but common step. |
| Azure Database for PostgreSQL and MySQL | 1 Ready to move directly | Managed PostgreSQL or MySQL (STACKIT, IONOS, Open Telekom Cloud) | Standard engines with standard migration tools. Replication keeps the cutover window short. |
| Azure Cache for Redis | 1 Ready to move directly | Managed Valkey or Redis (Exoscale, OVHcloud) | Same protocol, so this is usually a configuration change. |
| Azure Cosmos DB | 3 Deeply embedded | Data model redesigned for PostgreSQL, MongoDB or similar | No direct equivalent elsewhere. Usually the most involved part of the move, and it removes one of the biggest sources of lock-in. |
| Azure Service Bus | 2 Move with adjustments | RabbitMQ or another AMQP broker | Service Bus speaks AMQP, so messaging patterns map well. Client code changes. |
| Azure Event Hubs | 2 Move with adjustments | Apache Kafka | Event Hubs already offers a Kafka-compatible endpoint, which makes the switch easier. |
| Azure Event Grid | 2 Move with adjustments | Event bus on Apache Kafka or NATS | Subscriptions and routing are rebuilt. |
| Azure Logic Apps | 3 Deeply embedded | Workflow engine (Temporal) or automation tool (n8n) | Low-code workflows depend on Azure connectors and get rebuilt. Decide workflow by workflow. |
| Azure Notification Hubs | 2 Move with adjustments | Self-hosted push server in Europe (such as Gorush) sending to Apple and Google | Notification Hubs only relays messages to Apple's and Google's push services. An open push server in Europe takes over that job, and device registrations move with it. |
| Azure API Management | 2 Move with adjustments | Open API gateway (Kong, Traefik) or Kubernetes ingress | Routes move over. Policies are rewritten. |
| Microsoft Entra ID | 3 Deeply embedded | Often stays where it is. Otherwise Keycloak or Zitadel | Apps sign in through open standards (OpenID Connect, SAML), so Entra ID keeps working wherever they run. Replacing it is a separate decision. |
| Azure Key Vault | 2 Move with adjustments | Provider KMS or OpenBao, with keys only you control | Secrets move easily. Keys are re-created and data is re-encrypted under them. |
| Azure Synapse Analytics | 2 Move with adjustments | ClickHouse or Apache Spark | Most SQL carries over. Pipelines are adapted. |
| Azure OpenAI | 2 Move with adjustments | Sovereign AI platform with open or European models | Prompts and application logic stay. The model endpoint changes. |
| Azure Machine Learning | 2 Move with adjustments | Open MLOps tooling (MLflow, Kubeflow) on European GPUs | Models usually stay the same. Training, deployment and monitoring are rebuilt around them. |
| Azure AI services (Vision, Speech, Language) | 2 Move with adjustments | Open models hosted in Europe | Each API is replaced individually, and quality is tested per use case. |
| Azure Front Door and Azure CDN | 1 Ready to move directly | European CDN | Cache and routing rules are recreated. The cutover itself is a DNS change. |
| Azure DNS | 1 Ready to move directly | DNS at a European provider | Zones export as standard zone files. |
| Google Cloud | |||
| Compute Engine | 1 Ready to move directly | Compute instances (STACKIT, Exoscale, gridscale) | Images and configurations move with standard tools. A good moment to right-size. |
| Google Kubernetes Engine (GKE) | 1 Ready to move directly | Managed Kubernetes (STACKIT SKE, Exoscale SKS, gridscale) | Manifests and Helm charts move largely as they are. Provider-specific add-ons (load balancers, identity hooks) are swapped. |
| Cloud Run | 1 Ready to move directly | Containers on managed Kubernetes with Knative | Cloud Run is built on Knative, so containers run unchanged. The integrations around them need rework. |
| App Engine | 2 Move with adjustments | Containers on managed Kubernetes | Each app is containerized once. App Engine services and settings are replaced. |
| Cloud Functions | 2 Move with adjustments | Functions on Kubernetes (Knative) or plain containers | The code moves easily. Rebuilding the triggers and integrations takes most of the effort. |
| Cloud Storage | 1 Ready to move directly | S3-compatible object storage (STACKIT, Open Telekom Cloud, plusserver) | Cloud Storage has an S3-compatible API, so the data moves with standard tools. Apps using Google's client libraries switch libraries. |
| Persistent Disk and Filestore | 1 Ready to move directly | Block and file storage at the target provider | Moves together with the servers that use it. |
| Cloud SQL | 1 Ready to move directly | Managed PostgreSQL, MySQL or SQL Server (STACKIT, IONOS, Open Telekom Cloud) | Standard engines with standard migration tools. Replication keeps the cutover window short. |
| Memorystore | 1 Ready to move directly | Managed Valkey or Redis (Exoscale, OVHcloud) | Same protocol, so this is usually a configuration change. |
| Firestore and Realtime Database | 3 Deeply embedded | Open document or relational database (MongoDB, PostgreSQL) | Real-time sync and security rules are rebuilt with open building blocks. We size the effort before anything moves. |
| Bigtable | 2 Move with adjustments | Apache HBase or a Cassandra-compatible store | Bigtable supports the HBase API, which eases the move. Schemas and access patterns are checked. |
| Spanner | 3 Deeply embedded | PostgreSQL, or a distributed SQL database | Global consistency is a Google-specific feature. Decide first whether you really need it. |
| Pub/Sub | 2 Move with adjustments | Apache Kafka or NATS | Messaging patterns map well. Client code changes. |
| Cloud Tasks and Workflows | 2 Move with adjustments | Job queue or workflow engine (Temporal, Argo Workflows) | Workflows are re-expressed in the new engine. |
| Apigee | 2 Move with adjustments | Open API gateway (Kong, Traefik) or Kubernetes ingress | Routes move over. Policies are rewritten. |
| Firebase Cloud Messaging (push notifications) | 2 Move with adjustments | Self-hosted push server in Europe (such as Gorush) sending to FCM and Apple | On most Android phones, push always travels through Google, wherever your backend runs. What moves is the sending side, and messages can be kept free of personal data. |
| Firebase Authentication and Identity Platform | 2 Move with adjustments | Provider-independent identity platform (Keycloak, Zitadel) | Users can be exported with their password hashes, so nobody has to set a new password. |
| Cloud IAM | 2 Move with adjustments | Access management of the target platform, managed as code | Policies are rewritten for the new platform, ideally as code in Terraform. |
| Secret Manager and Cloud KMS | 2 Move with adjustments | Provider KMS or OpenBao, with keys only you control | Secrets move easily. Keys are re-created and data is re-encrypted under them. |
| BigQuery | 2 Move with adjustments | ClickHouse at a European provider | Usually treated as its own migration project. Specialized features your reports rely on are checked upfront. |
| Dataflow | 2 Move with adjustments | Apache Beam on Flink or Spark | Dataflow runs Apache Beam, which also runs on open engines. Pipelines largely carry over. |
| Dataproc | 1 Ready to move directly | Apache Spark on managed Kubernetes | Open-source Spark and Hadoop jobs move with little change. |
| Vertex AI | 2 Move with adjustments | Open MLOps tooling (MLflow, Kubeflow) on European GPUs | Models usually stay the same. Training, deployment and monitoring are rebuilt around them. |
| Gemini API | 2 Move with adjustments | Sovereign AI platform with open or European models | Prompts and application logic stay. The model endpoint changes. |
| Firebase Hosting | 1 Ready to move directly | Static hosting or CDN at a European provider | Static sites move as they are. |
| Cloud CDN and Cloud DNS | 1 Ready to move directly | European CDN and DNS | Cache rules are recreated and zones export as standard files. Cutover is a DNS change. |
Here’s the honest answer: not everything has to move, and not everything should. A good migration plan starts by sorting out what’s easy, what’s worth doing, and what can stay put.
Amazon Web Services
Learn where AWS lock-in typically occurs, which European providers are good alternatives, and how a migration can affect your cloud costs.
Microsoft Azure
See which Azure services are easiest to migrate, where you’ll need adjustments, and how to approach services like Azure Functions and Cosmos DB.
Modern European cloud providers deliver high availability, the cloud services you actually need, and often lower total costs. For many companies, they’re a real alternative to the big hyperscalers now. Pick any two in the comparison below and see how they stack up.
| Criterion | ExoscaleSwitzerlandDeveloper-first, nearest zones | HetznerGermanyCheapest, most do-it-yourself | IONOS CloudGermanyBroadest platform under German law | MittwaldGermanyManaged hosting, not infrastructure | Open Telekom CloudGermanyDeutsche Telekom scale and contracts | OVHcloudFranceWidest European footprint | plusserverGermanyAudit-ready compliance paperwork | STACKITGermanyEnterprise-grade sovereignty |
|---|---|---|---|---|---|---|---|---|
| Ownership | A1 Digital, part of A1 Telekom Austria Group | Hetzner Online GmbH, independently held | IONOS SE, part of United Internet | Mittwald CM Service, owner-managed, Espelkamp | T-Systems International, part of Deutsche Telekom | OVH Groupe, listed on Euronext Paris, founded in Roubaix | plusserver GmbH, Cologne | Schwarz Digits, part of the Schwarz Group (Lidl, Kaufland) |
| European regions | Switzerland, Austria, Germany, Bulgaria, Croatia | Germany (Falkenstein, Nuremberg), Finland (Helsinki) | Germany, UK, France, Spain | Germany only | Germany (Biere and Magdeburg twin-core), Netherlands, Switzerland | France, Germany, Italy, Poland, UK, plus local zones across Europe | Four data centers across the DACH region | Seven European data centers, Germany-anchored |
| Sovereignty credentials | ISO 27001 / 27017 / 27018, SOC 2, BSI C5, CSA STAR | ISO 27001, BSI C5, GDPR | ISO 27001, BSI C5, GDPR, no data resale | ISO 27001 | BSI C5:2020 Type II, ISO 27001 / 27017 / 27018 | ISO 27001 / 27017 / 27018 / 27701, SecNumCloud on selected private cloud offers | ISO 27001 and 9001, BSI C5 Type II, ISAE 3402 Type II, PCI DSS, IT-Grundschutz | BSI C5, ISO 27001, TÜV SÜD, GDPR |
| Offered services |
|
|
|
|
|
|
|
|
| Pricing model | Predictable flat pricing, consistent across regions | Flat monthly rates, generous included traffic, cheapest of the eight | Usage-based with savings plans, positioned well under hyperscaler list prices | Managed hosting plans, not usage-based infrastructure | Pay-as-you-go, with discount models and capacity reservations | Hourly or monthly with savings plans, network traffic included | Managed-service pricing, Kubernetes from roughly €67 a month | Enterprise agreements, quoted rather than self-serve |
| Support model | Engineer-led, Europe-based | 24/7 ticket and email, no account team | Phone and ticket, technical support around the clock | German-language support built around agency workflows | 24/7 European teams in German and English, free consulting | Four tiers, up to 24/7 with a one-hour response and a technical account manager | German managed-service teams | Enterprise support, German-language |
| Best fit for | Product teams that live in Kubernetes and want a nearby EU zone | Cost-driven workloads and teams happy to run their own platform layer | Teams wanting a broad, hyperscaler-shaped feature set under German jurisdiction | Agencies and freelancers hosting client sites, not a hyperscaler replacement | Enterprises that want a Deutsche Telekom contract and a large service catalog | Teams that want hyperscaler breadth, GPUs and the most European locations | Healthcare, public sector and finance workloads that need audited paperwork | Regulated workloads where sovereignty is a board-level requirement |
We’re not tied to any of these providers, and we don’t earn commissions. Our recommendation follows your workflows, not our partner list.
When you build a new house, you don’t copy the old floor plan. Cloud environments accumulate technical debt over time: oversized resources, unused services, and unnecessary complexity. Migration is your chance to leave those behind instead of carrying them into a new environment. We keep what works and change what doesn’t.
PHASE 1
2 to 6 weeks, depending on scope
Outcome: We assess your environment, define the target architecture, plan the migration, and build the new cloud environment.
PHASE 2
3 to 12 months, depending on the environment
Outcome: A controlled migration with no big-bang cutover. Each workflow moves on its own schedule. We run it in parallel, test it, and switch over when it’s ready.
PHASE 3
Ongoing, on your model
Outcome: Once the migration is complete, your team can take over with documentation and training. Or we can continue operating the platform under clearly defined service levels.
Trusted by great companies
Get a first read on effort, architecture, and implementation options within 24 hours.
Don’t worry: the information you share is only used for business purposes. You’ll find more details in our privacy policy.
Would you rather speak directly with our expert? Tell us what’s prompting it: a question from an auditor, pressure from a client, or a cloud bill that finally got your attention. You’ll get an honest answer, even if it’s that this can wait.
Miki
Senior Consultant
[email protected]
Don’t worry, whatever it is, we’ve got you covered in our FAQ.
That depends on scope and the mix of categories, so we won’t quote a flat fee.
After the cloud analysis, you’ll get a fixed price range for each migration wave. And the math isn’t just about one-time cost. Factor in the permanently lower running costs too, since they often make up for the upfront investment within a reasonable timeframe.
Yes.
Certified data centers, guaranteed uptime, and redundant locations are standard practice among established providers. Trading companies, banks, and government agencies already run production workloads on them.
The real difference isn’t operational quality. It’s portfolio breadth and legal jurisdiction, and we clarify both upfront during the analysis.
No, and that’s often not even the right move.
Usually the systems that move are the ones where data sovereignty and cost savings matter most, while anything non-critical stays put. The result is a deliberate split, not an all-or-nothing decision.
A single backend system typically takes three to six months.
Larger environments with multiple systems run six to twelve months or more. Our cloud analysis gives you a solid estimate for your specific case upfront.
No.
We build the target environment in parallel and switch over system by system, only after each one’s been tested and running there. In most cases, your applications and your customers won’t notice a thing.
We run every sovereignty check against the same model: four dimensions, proven across the industry.
