From Lift-and-Shift to Landing Zones
A lift-and-shift migration gets you to the cloud. It doesn't get you a cloud architecture. Here's what we build instead for clients migrating for real.
Nearly every cloud migration we're brought in on has already had a first attempt: lift-and-shift the existing servers into VMs, call the migration done. It works, in the sense that the lights stay on. It also means the client is now paying cloud prices for on-premises architecture, with none of the actual benefits of the platform they just moved to.
What lift-and-shift actually preserves
Lift-and-shift preserves your existing architecture's assumptions — fixed capacity, manual scaling, a single region, security groups that were designed for a data center's physical perimeter rather than a cloud provider's identity model. None of that is wrong on-premises. All of it is expensive and fragile once it's running as VMs in someone else's data center.
What a landing zone actually is
A landing zone is the account and network structure a workload lands into before any application code is deployed — multi-account separation by environment and function, centralized identity and logging, and network boundaries defined by traffic patterns rather than physical topology.
# Simplified shape of our standard landing zone account split
module "landing_zone" {
accounts = {
security = { purpose = "centralized logging, guardrails" }
network = { purpose = "shared VPC, transit gateway" }
prod = { purpose = "production workloads" }
nonprod = { purpose = "staging, dev" }
}
scp_guardrails = ["deny-root-account-usage", "require-encryption-at-rest"]
}
The account structure is the part clients most often want to skip, because it feels like overhead before any application work happens. It's also the part that's genuinely painful to retrofit later — every workload deployed into the wrong structure has to be migrated twice.
The migration we actually recommend
We now run every cloud migration in two distinct phases, explicitly separated: first the landing zone (accounts, identity, network, guardrails), then application migration into that structure — never both at once, and never application-first. Clients who've done lift-and-shift before are often surprised how much faster the second, "real" migration goes, because the landing zone removes a whole category of decisions from every subsequent workload move.
"The landing zone isn't infrastructure you build once and forget. It's the decision you're making, once, on behalf of every workload you'll ever migrate after this one."
Landing zone account structure with security, network, prod, and nonprod accounts
What changes for the client afterward
Beyond cost (most clients see meaningful savings simply from right-sizing instead of matching on-premises specs 1:1), the bigger shift is operational: security reviews go from "audit every server" to "audit the guardrails," and onboarding a new workload becomes a known, repeatable process instead of a bespoke project every time.
One email, every other Friday
Engineering notes, new articles, and things we learned the hard way — no marketing, ever.
Read by 2,400+ engineers. Unsubscribe anytime.
Let's talk
Let's build what's next.
If any of this sounds like the kind of work you want done on your systems, our engineers are the ones who'll actually do it.