Cloud Migration
Cloud migration refers to moving applications, data and infrastructure from your own data center to a cloud environment. The spectrum ranges from an unchanged move (rehosting) to a cloud-native rebuild — which path is viable depends on the application, regulation and economics.
Migration strategies at a glance
A widespread classification scheme distinguishes six strategies — the “6 Rs”:
| Strategy | Approach | Typical use |
|---|---|---|
| Rehost (lift-and-shift) | move the application unchanged to cloud infrastructure | fast data center exit, little benefit beyond that |
| Replatform | selective adjustments, e.g. switching to a managed database | reduce operational effort at moderate cost |
| Refactor / re-architect | rebuild towards a cloud-native architecture | strategic core systems with a long remaining lifetime |
| Repurchase | replacement with a SaaS product | standard functions without differentiating value |
| Retire | shut down the application | unused or redundant systems |
| Retain | deliberately keep as is (for now) | systems with high coupling, regulatory hurdles or imminent replacement |
Real portfolios almost always use a mix — the strategy is decided per application, not across the board for the entire landscape.
More than a move: cloud-native as the target picture
The promised benefits of the cloud — elasticity, shorter release cycles, lower operational effort — do not come from the change of location, but from the architecture: containers and orchestration (Docker, Kubernetes), managed services instead of self-operation, infrastructure as code (such as Terraform), automated CI/CD pipelines and often a decomposition into microservices or event-driven systems.
A pure lift-and-shift, on the other hand, carries the data center sizing and architecture 1:1 into the cloud — and thus frequently becomes more expensive than before, because capacity is paid for around the clock that was already written off on-premises.
Regulated industries: sovereignty as a framework condition
For banking, insurance and critical infrastructure, classic public cloud setups quickly hit hard legal, regulatory and data protection limits (such as BaFin requirements and GDPR). Viable answers are hybrid architectures and private cloud environments in German or European data centers, as well as architectures compatible with sovereign cloud initiatives such as Gaia-X. The choice of provider — whether AWS, Azure or a European hoster — should be made in a vendor-neutral way based on the economic and regulatory criteria of the specific use case, not on vendor roadmaps.
Cloud migration in practice: when it is not worth it
Not every application belongs in the cloud — an honest assessment per application therefore comes before any strategy:
- Stable, predictable load: If a system runs steadily on existing hardware, self-operation is often cheaper — elasticity only pays off with fluctuating load.
- Imminent replacement: For systems that will soon be shut down or replaced anyway, the migration effort is no longer worthwhile.
- Data and latency requirements: High data transfer costs or hard latency requirements can speak against the cloud.
- Migration without a target picture: Those who only change location without adapting architecture and operations pay more for the same state.
Moving individual workloads back out of the cloud (repatriation) also happens in practice — it is not a failure, but part of ongoing portfolio management.