Why Moving to the Cloud Is Not Just a Simple Lift‑and‑Shift: Lessons on Elasticity, Stateless Design, and Architecture

Many assume that moving an existing system to the cloud is as easy as a direct lift‑and‑shift, but real‑world experiences show that without a flexible architecture this leads to waste and performance problems.

Case 1 – No‑cloud predicament: A legacy core system running on a powerful 3+3 Oracle RAC cluster (described as a “Ferrari”) was upgraded but remained under‑utilized due to inflexible capacity planning, long procurement cycles, and the inability to scale horizontally, resulting in costly over‑provisioning.

Case 2 – Blind cloud migration: Another legacy monolith was moved to the cloud but still required a single high‑spec server because its architecture relied heavily on stored procedures and database‑centric logic, preventing horizontal scaling and negating cloud benefits.

The article distinguishes vertical scaling (scale‑up) – increasing CPU, memory, etc. – from horizontal scaling (scale‑out) – adding more servers – and outlines the limitations of vertical scaling such as non‑linear performance gains, hardware caps, higher costs, and lack of live scaling.

Cloud advantages stem from horizontal scaling combined with load balancing, monitoring, and auto‑scaling groups, enabling resources to be allocated dynamically during peak loads and released during low demand, thus optimizing cost and performance.

To fully exploit cloud elasticity, applications must be stateless, with most business logic residing in the application layer while state is kept in databases or shared storage. Stateless services can be deployed, scaled, and terminated without affecting functionality.

Monolithic systems should be decomposed into services or micro‑services, allowing independent scaling and easier management. Asynchronous communication (e.g., using message queues) decouples services, improves resilience, and supports peak‑load handling by prioritizing critical paths.

In summary, cloud migration succeeds only when the underlying architecture embraces stateless design, service decomposition, and asynchronous patterns, turning a single “black‑box” into a manageable, elastic set of components.