The Three Prepositions of Cloud Adoption
On the cloud, in the cloud, for the cloud — a maturity model for cloud adoption.
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 3
- Confidence
- 82%
As enterprises adopted AWS, a clear maturity progression emerged for how deeply they took advantage of cloud infrastructure. The first stage, building 'on' the cloud, is simple lift-and-shift: moving existing infrastructure unchanged into AWS's data centers to gain pay-as-you-go economics without re-architecting anything. The second stage, building 'in' the cloud, means adopting managed cloud-native services (like RDS) that replace self-hosted infrastructure while keeping the same application logic. The third and most advanced stage, building 'for' the cloud, means fully re-architecting applications around cloud-native primitives like Lambda and DynamoDB, unlocking serverless scalability. This model explains why competitors who tried to skip straight to an advanced platform-layer offering (Microsoft, Google) missed the market, while AWS captured customers by meeting them wherever they were on this maturity curve.
Origin
Articulated by the Acquired hosts analyzing AWS's product strategy versus Andy Jassy's public re:Invent framing of cloud value stages.
Core principles
- 01Cloud value isn't binary — it exists on a maturity spectrum
- 02Lift-and-shift captures cost savings but not architectural benefits
- 03Cloud-native services let you keep familiar architecture while gaining managed infrastructure
- 04Full serverless re-architecture captures the most value but requires the most redesign
- 05Vendors must support customers at every stage, not just the most advanced one
How to run it
- 1
Build ON the Cloud (Lift and Shift)
Move existing infrastructure and applications unchanged into the cloud provider's data centers, paying only for what you use instead of buying and maintaining hardware.
Pro tip This is the easiest and fastest first step for legacy migrations.
Watch out You gain none of the cloud-native performance or cost advantages at this stage.
- 2
Build IN the Cloud (Cloud-Native Managed Services)
Replace self-hosted infrastructure components (like a self-managed database) with managed cloud-native equivalents such as Amazon RDS, while keeping the same application logic and queries.
Pro tip Look for managed services that are drop-in compatible with what you're already running.
- 3
Build FOR the Cloud (Full Cloud-Native Re-Architecture)
Redesign the application entirely around cloud-native primitives like Lambda (serverless compute) and DynamoDB, so infrastructure concerns like servers and IP addresses disappear entirely.
Pro tip Reserve this step for new projects or major rewrites — it requires the deepest redesign.
Watch out Building here too early, before customers understand the paradigm, can leave you without product-market fit (as happened to early platform-as-service offerings).
In the wild
Netflix had built its own internal streaming infrastructure before ultimately abandoning it and moving its systems onto AWS, becoming one of the platform's largest and most vocal customers.
→ Netflix became a flagship example of an enterprise successfully migrating mission-critical infrastructure to the cloud.
A new application built from scratch using Lambda functions and DynamoDB never provisions or manages a server at all, scaling automatically with usage and paying only for execution time.
→ Near-zero infrastructure overhead and automatic scaling from day one.
Common mistakes
Jumping to Platform-as-a-Service Too Early
Microsoft and Google both tried to launch far-future cloud-native platforms before the market was ready, missing both startups (no mature platform yet) and enterprises (no lift-and-shift path).
Assuming Lift and Shift Is the Finish Line
Staying permanently in the 'on the cloud' stage means missing most of the cost and performance benefits cloud-native architecture can provide.
Ignoring Switching Costs When Advancing Stages
Moving deeper into cloud-native, proprietary services increases vendor lock-in, which must be weighed against the performance gains.
Is it for you?
Best for
Enterprises or vendors planning a multi-year cloud migration or cloud product roadmap.
Not ideal for
Greenfield startups with no legacy infrastructure, who can often skip straight to building 'for' the cloud.
From the transcript
“there's these sort of three prepositions of the cloud there's people building on the cloud which to me that's lift and shift”
“then there's building for the cloud and that's the future and that's things like lambda and dynamodb”
From the episode
Amazon Web Services