---
title: "Cloud Provider Selection"
description: "Structured decision process for cloud provider selection: evaluation matrix, selection criteria, STACKIT positioning and typical decision pitfalls."
sidebar:
  order: 6
  label: "Cloud Provider Selection"
source_url: "https://framework.stackit.cloud/advisory/cloud-vision-and-strategy/provider-selection/"
source_file: "docs/advisory/cloud-vision-and-strategy/provider-selection.mdx"
---

## Why the provider decision is strategic

The choice of cloud provider is not an IT decision — it is a strategic decision with 5–10 years of relevance. Wrong provider decisions create lock-in, compliance risks and migration costs running into eight figures.

The most common decision pitfall: provider selection is made based on product feature lists and price negotiations, without weighting the strategic dimensions (sovereignty, portability, regulatory compliance).

## Multi-cloud vs. single-cloud: the strategic decision

Many organisations arrive with a multi-cloud question: "Should we use STACKIT and another provider?"

**When multi-cloud makes sense:**  
Workloads with different sovereignty profiles (Tier 1 on STACKIT, global CDN infrastructure on other providers); specific capabilities that STACKIT does not yet offer at the same maturity; existing investments with another provider that cannot be migrated immediately.

**When single-cloud (STACKIT) is the better choice:**  
A clear sovereignty obligation for all or most workloads; simpler governance, unified toolchain, no cross-cloud complexity; a DACH-focused organisation without global deployment requirements.

**The pitfall warning:** Multi-cloud as a strategy sounds attractive but is expensive in practice — double tooling, double training, double governance complexity. Many organisations that start with multi-cloud consolidate after 2–3 years.

## Vendor lock-in: architectural protection with STACKIT

STACKIT's open-standards approach provides structural protection against lock-in:

| Technology              | STACKIT implementation                   | Exit path                        |
| ----------------------- | ---------------------------------------- | -------------------------------- |
| Container orchestration | SKE (STACKIT Kubernetes Engine)          | Any CNCF-conformant K8s provider |
| Infrastructure as Code  | STACKIT Terraform Provider               | Terraform knowledge is portable  |
| Object storage          | S3-compatible API                        | Any S3-compatible provider       |
| Managed databases       | PostgreSQL, MySQL, Redis (standard APIs) | Self-operable                    |

This means: a STACKIT exit is possible without rewriting the entire IaC library.

## Decision process: structured, not political

A poor provider decision process looks like this: IT presents a recommendation, the board asks why not the well-known US provider, the decision is made based on brand recognition.

A good process:

1. **Adopt the evaluation matrix with weightings in the Steering Committee** before evaluating providers — not after
2. **Proof of concept** with the top 2 providers for a defined test workload
3. **Security/compliance assessment** by CISO and DPO
4. **TCO analysis** over 3 years (not just list prices)
5. **Decision documentation**: why this provider, why not the others — for later review

## Practical steps

1. **Adapt the evaluation matrix** to your North Star and sovereignty profile
2. **Run a STACKIT PoC** for a Tier 1 workload
3. **CISO assessment** of Cloud Act risks for current providers in the portfolio
4. **TCO comparison** including hidden costs (egress, support, compliance tooling)
5. **Formalise the decision in the Cloud Strategy Board**