Why 'Lift and Shift' Usually Fails in Regulated Clouds
What 'Lift and Shift' Promises — and Where the Promise Breaks
The math sounds simple: pull the server images, restart them in the cloud, switch off the data centre. "Lift and shift" promises fast migration without rebuilding applications, without expensive refactoring, without projects that drag on for months. For many IT leaders in regulated organisations, this is the pragmatic entry point — and that is exactly where the problem begins.
In regulated environments — banks, insurers, critical-infrastructure operators — one-to-one migration rarely fails on technical grounds. It fails because it carries the organisation's grown risk and control model across unchanged. What worked on-premises does not automatically hold in the cloud. And what counted as evidence in your audits often no longer exists in that form once you are in the cloud.
Risk Travels With You — It Does Not Disappear
A one-to-one migration reduces no risk. It relocates it. The misconfiguration that was barely exploitable in your own data centre, buried behind several network layers, suddenly sits on an entirely different attack surface in the cloud. The outdated service that was never publicly reachable on-premises now hangs off an environment whose default assumptions are different.
On top of that, you add new attack surfaces. The cloud control plane, identity and access management, API endpoints, network and storage configuration — none of that existed on-premises in this form, or it sat within a different area of responsibility. The most common weak spot is not the cloud platform itself but the way customers configure it. Industry forecasts have for years assumed that the majority of cloud security incidents stem from customer-side misconfigurations rather than provider errors. Anyone who lifts their system across unchanged, without understanding the new control logic, migrates their weaknesses along with it — and adds fresh ones.
Compliance Works Differently in the Cloud
Germany's NIS-2 implementation act has been in force since 6 December 2025. Section 30 BSIG transposes Article 21 of the NIS-2 Directive and obliges essential and important entities to put in place technical and organisational risk-management measures that must be appropriate, proportionate and effective. The catalogue names at least ten areas of measures — including risk analysis, handling of security incidents, backup and crisis management, access control, and the security of the supply chain, including relationships with service providers and vendors.
That last point is decisive in the cloud. Because when you move, you do not take on full control of the infrastructure — you share it. Under the shared responsibility model, the security of the underlying infrastructure lies with the provider, while you as the customer remain responsible for the operating system, the applications and the configuration of the security mechanisms provided. AWS describes it explicitly: whoever runs an EC2 instance is responsible for the guest operating system, including updates and patches, for the installed software, and for the configuration of the firewall provided — the security group — on each instance (AWS Shared Responsibility Model).
For evidencing purposes, this means your familiar artefacts shift. On-premises, your proof of network segmentation might have been a firewall rule set and a network diagram. In the cloud it becomes a combination of configuration states, identity policies and automatically captured evidence. The notification duties are just as concrete: security incidents must be reported to the BSI within tight deadlines — an early initial notification within 24 hours, a report within 72 hours, and a final report after one month at the latest. These deadlines presuppose that you can even detect and evidence incidents in the cloud in good time — which is not a given without adapted logging and monitoring. The BSI sets out the duties in detail on its page for NIS-2-regulated organisations.
A Conceptual Example: Network Segmentation
Take network segmentation. On-premises you think in zones: a DMZ segment, an internal segment, a high-security back-end segment, separated by firewalls and in some cases by physical boundaries. Control is topological — a system's location in the network determines what it is allowed to talk to.
Carry this logic across to the cloud one-to-one, and you recreate the zones as subnets and try to enforce the same topological separation. On the surface it works — but it leads you astray. In the cloud the primary control is no longer location in the network but identity and configuration. Security groups operate per instance and can be tied to identities and resource attributes, not just to subnet boundaries. Anyone who rebuilds the old zone logic gives away precisely the depth of control the cloud offers — while keeping the brittleness of the old structure. Segmentation that was maintained on-premises as a rigid rule set becomes, in the cloud, a matter of clean, verifiable configuration.
The same shift applies to workloads you run in containers or under orchestration. Anyone who packages existing applications into containers and lifts them into a managed Kubernetes cluster often carries over implicit assumptions about network, permissions and isolation that no longer hold in the new context. Here too, a pure move reduces no risk — it relocates it to a layer whose control and evidencing mechanisms have to be understood anew.
A Procedural Heuristic: Four Steps Before Migration
Rather than diagnosing what goes wrong, here is a sober sequence that has proven itself in practice:
1. Settle the control model before the workload. First determine which controls (segmentation, access, logging, evidence) will be implemented in the target environment and how — before the first instance is migrated. The control model is the blueprint, not the application.
2. Map evidencing duties to cloud artefacts. Work through your Section 30 BSIG-relevant measures and define, for each one, which cloud artefact will serve as evidence going forward. What you cannot evidence counts, in case of doubt, as not implemented.
3. Make shared responsibility explicit. For every migrated component, draw the line between provider and customer responsibility. Document which configuration is in your hands — and who checks it.
4. Treat misconfiguration as a standard risk. Before the move, establish automated checks of the configuration against established baselines (such as CIS Benchmarks). That way you catch the most common type of incident before it goes into production.
Where You Can Start
The first step is not a migration but an honest assessment of where you stand: how mature are your controls for software development and containerised workloads, really? Our free SDLC & Kubernetes Security Self-Check walks you through 64 weighted controls and returns a maturity level from 0 to 4. The check runs entirely locally in your browser, no data leaves your device, and the result can be exported as a report.
Anyone standing before — or in the middle of — a cloud migration gains a solid baseline from this, before relocated risk turns into a reportable incident.