Azure → STACKIT

Migrating from Azure to STACKIT

STACKIT is the sovereign-by-design cloud of the Schwarz Group (owner of Lidl and Kaufland), run entirely from German and Austrian datacentres with BSI C5 attestation. It is the natural Azure exit for a German-data-residency mandate. But the two Azure-specific edges matter: STACKIT storage is S3, not Azure Blob, so SDK code is rewritten rather than repointed, and there is no managed identity service to replace Azure AD B2C. This page is concrete about both.

Which Azure services have a true STACKIT equivalent?

Graded conservatively. The catch for Azure shops is that “S3-compatible” means “not Azure Blob-compatible”: a code change, not a config change.

Azure services and their STACKIT equivalents, each with a migration verdict.
AzureSTACKITVerdict
Azure Blob StorageSTACKIT Object Storage S3-compatible, which means NOT Azure Blob-compatible. Every SDK call, SAS-token flow and container operation is rewritten against the S3 API, not repointed.Partial
Azure Managed DisksSTACKIT Block Storage OpenStack-backed block volumes with snapshots. Direct equivalent.Equivalent
Azure Virtual MachinesSTACKIT Compute (OpenStack) General-purpose instances across the German and Austrian regions.Equivalent
Azure AKSSTACKIT Kubernetes Engine (SKE) Managed Kubernetes with a free control plane; node pools spread across the region’s availability zones.Equivalent
Azure Database for PostgreSQLSTACKIT PostgreSQL Flex Managed PostgreSQL; also MariaDB, Redis/Valkey, MongoDB and OpenSearch flavours.Equivalent
Azure Cache for RedisSTACKIT Redis / Valkey Managed in-memory cache. Covered.Equivalent
Azure Key VaultSTACKIT Secrets Manager Managed secret storage. Migrate secrets and rewire references.Equivalent
Azure Service BusSTACKIT RabbitMQ Queue and pub/sub via managed RabbitMQ, but Service Bus topics, sessions and dead-letter semantics do not map one-to-one.Partial
Azure FunctionsNo managed twin No serverless functions. Event-driven code runs on SKE or VMs.No managed twin
Azure AD B2CNo managed twin (self-host Keycloak) No managed customer-identity service; CIAM moves to self-hosted Keycloak or an EU IdP, a project in its own right.No managed twin
Azure Cosmos DBNo managed twin (self-host) No managed globally-distributed NoSQL twin.No managed twin
Azure SynapseNo managed twin (self-host ClickHouse) No sovereign serverless warehouse; ClickHouse is a different operating model.No managed twin

Where do the Azure APIs actually diverge?

These are Azure-specific, not the generic AWS edges: the things a team leaving Azure underestimates.

  • STACKIT Object Storage is S3-compatible, so it is not Azure Blob-compatible: the Azure Storage SDK, SAS tokens and container semantics are all rewritten against S3, not repointed.
  • There is no managed identity service to replace Azure AD B2C. Customer identity moves to self-hosted Keycloak or an EU CIAM, which is a distinct workstream.
  • Service Bus topics, sessions and dead-letter behaviour do not map cleanly to RabbitMQ; messaging is re-modelled, not lifted.
  • No serverless functions, no Cosmos DB and no Synapse twin: event-driven and analytics workloads are re-platformed.

Which of your services move cleanly?

Scoped to the rows STACKIT covers as managed services. Search or filter by verdict.

7 capabilities

  • Object storage

    Hyperscaler Amazon S3 Azure Blob Storage Google Cloud Storage
    EU-sovereign path Scaleway Object StorageOVHcloud Object Storage
    Verdict Mature

    S3-compatible API. A drop-in target for most SDKs, backups and static assets.

  • Block storage

    Hyperscaler Amazon EBS Azure Managed Disks Persistent Disk / Hyperdisk
    EU-sovereign path Scaleway Block StorageOVHcloud Block Storage
    Verdict Mature

    Network block volumes with snapshots. Standard building block, well covered.

  • Virtual machines

    Hyperscaler Amazon EC2 Azure Virtual Machines Google Compute Engine
    EU-sovereign path Scaleway InstancesOVHcloud Public CloudHetzner Cloud
    Verdict Mature

    General-purpose and dedicated instances are a solved problem in the EU.

  • Managed Kubernetes

    Hyperscaler Amazon EKS Azure AKS Google Kubernetes Engine (GKE)
    EU-sovereign path Scaleway KapsuleOVHcloud Managed Kubernetes
    Verdict Mature

    CNCF-conformant managed control planes. Portable workloads move with little friction.

  • Managed PostgreSQL

    Hyperscaler Amazon RDS / Aurora Azure Database for PostgreSQL Cloud SQL / AlloyDB for PostgreSQL
    EU-sovereign path Scaleway Managed DatabaseOVHcloud Managed DatabasesAiven for PostgreSQL
    Verdict Viable

    Standard PostgreSQL is well served. Aurora-specific features (e.g. global database, serverless v2 autoscaling) have no exact twin, so plan around them.

  • Managed cache (Redis/Valkey)

    Hyperscaler Amazon ElastiCache Azure Cache for Redis Memorystore for Redis
    EU-sovereign path Scaleway Managed Database for RedisAiven for Valkey/Redis
    Verdict Viable

    In-memory caching is well covered; Valkey is the emerging open successor to Redis.

  • Secrets & key management

    Hyperscaler AWS Secrets Manager / KMS Azure Key Vault Secret Manager / Cloud KMS
    EU-sovereign path Scaleway Secret ManagerHashiCorp Vault (self-hosted)
    Verdict Viable

    Managed secret storage exists; self-hosted Vault gives full control including HSM-backed keys.

Verdicts are conservative and reflect managed, EU-jurisdiction offerings as of 2026. Provider feature sets move quickly, so we re-check on every engagement.

How many engineer-days does this take?

45–100 engineer-days

Higher at the low end than an AWS→EU move, because two Azure-specific rewrites (Blob→S3 and the identity layer) are almost always on the critical path.

  • A mid-sized Azure estate: VMs, AKS, Azure Database for PostgreSQL, Blob storage, Key Vault and an AD B2C identity tier.
  • The low end assumes AKS-, PostgreSQL- and disk-shaped workloads that map to SKE and STACKIT managed services.
  • The high end assumes a heavy Blob-SDK footprint to rewrite plus an Azure AD B2C tier to rebuild on Keycloak.
  • Excludes application rewrites, data egress from Azure and staff ramp-up on OpenStack-based tooling.

Where does STACKIT actually run?

Two EU regions, each with three availability zones. All customer data is stored exclusively in STACKIT’s own German and Austrian datacentres, with no US parent.

  • Germany (eu01)Region near Heilbronn with three availability zones (eu01-1/2/3).
  • Austria (eu02)Second EU region with three availability zones for DR and residency choice.

What are the honest limitations?

  • A young platform with a smaller catalogue STACKIT is newer than Azure, with a narrower service set and thinner third-party ecosystem: no serverless functions, no Cosmos/Synapse twin, and fewer regions.
  • Germany and Austria only, S3 not Blob Strong for German data residency (Schwarz Group, BSI C5), but there are no wider-EU or global regions, and the storage API is S3, so Azure Storage SDK code must be rewritten rather than repointed.

What else does a CTO ask before committing?

Why is leaving Azure harder than leaving AWS to an EU cloud?
Because two Azure-specific dependencies rarely have a drop-in EU twin: Blob storage (whose API is unlike S3) and Azure AD B2C (identity). Both are rewrites, not repoints, and they usually sit on the critical path, so budget for them explicitly.
Is STACKIT sovereign enough to satisfy German mandates?
It is among the strongest options: German-owned (Schwarz Group), data held only in Germany and Austria, BSI C5 attestation and no US parent. For a German-data-residency mandate it is a natural fit; confirm any sector-specific attestations you need.
What do we do about the identity tier?
Plan a dedicated workstream. Self-hosted Keycloak (or an EU-based IdP such as Zitadel) replaces Azure AD B2C, but user migration, token flows and app integrations are non-trivial. Treat it as its own project, not a line item.