A cloud migration without a written plan is a bill you haven't opened yet. The workloads run, the invoices arrive, and nobody on the team can tell you why one service costs six figures a month or who owns the identity reading the customer database at 3 a.m. A plan answers those questions before they turn into incidents. Lift-and-shift is the strategy most likely to skip writing one. Rehosting is a legitimate option on its own; the trouble starts when teams use it as a substitute for planning.
Myth: Lift-and-Shift Is a Migration Strategy on Its Own
Rehosting is one option in a menu, not the menu. AWS's Prescriptive Guidance describes seven migration strategies — retire, retain, rehost, relocate, repurchase, replatform, and refactor — and each workload is supposed to be evaluated against all of them before anyone provisions anything. Teams that skip the evaluation and default to rehost everywhere pay cloud prices for data center architectures. The application that ran fine on an over-provisioned VM in a colo now runs fine on an over-provisioned VM at a hyperscaler, for three times the cost and none of the elasticity.
A real plan assigns a strategy per workload, in writing, with the reason. Sometimes rehost is the right answer; a legacy system with a two-year sunset date doesn't need refactoring. Sometimes it's the lazy answer. The document is what forces you to say which.
Myth: The Cloud Bill Will Be Smaller by Default
Cost surprises are the most predictable outcome of an unplanned migration, and they show up in the second or third month, not the first. A rehosted workload keeps the shape it had on-premises: the same idle capacity, the same over-sized instances, the same nightly jobs that now generate egress charges nobody modeled. Reserved instance decisions then get made under pressure, and finance starts asking questions engineering can't answer without a spreadsheet nobody built.
A good plan prices the migration two ways: what the workload costs to run as-is in the cloud, and what it would cost after even modest replatforming. The delta is usually where the business case lives. For a closer look at how this goes sideways in practice, this rundown of the mistakes that derail a cloud migration covers the ones that turn up most often in post-mortems.
Myth: Identity and Access Can Be Sorted Out After the Cutover
Identity is where lift-and-shift stops being lift-and-shift. On-premises, a lot of access is implicit: a server sits on a trusted network, a service account was created in 2017 by someone who left in 2019, a shared credential lives in a config file nobody reviews. Move that workload to a public cloud and every one of those implicit trusts becomes an explicit permission that has to be granted, named, and owned.
Teams that defer this land in one of two failure modes. The permissive version grants broad roles to keep things working and discovers the blast radius during an audit. The restrictive version breaks the workload on day one and burns a week firefighting. A migration plan spells out the identity model — who authenticates, what federates, which service accounts get scoped down, what breaks when MFA is enforced — before the first workload moves.
Myth: A Runbook Is the Same Thing as a Plan
A runbook tells you how to move a workload. A plan tells you which workloads to move, in what order, with what dependencies, against what success criteria, and what happens when a wave fails. Google Cloud's migration guidance organizes the work into four phases — assess, plan, deploy, optimize — and the assess and plan phases are where dependency mapping, TCO modeling, and the identity and networking foundation get pinned down. Skip them and the deploy phase becomes a rolling incident.
The artifacts a real plan produces are boring and specific:
- A workload inventory. Every application, its owner, its dependencies, its data classification, and the strategy assigned to it.
- A wave schedule. Which workloads move together, which have to wait, and which get retired instead of moved.
- A landing zone spec. Accounts, networks, identity providers, logging, and guardrails, defined before anything lands in them.
- A rollback definition. What 'the migration failed' looks like for each wave, and what the team does when it happens.
Myth: You Can Fix the Architecture Later
Later rarely comes. Once a rehosted workload is running in production and the on-premises version has been decommissioned, the appetite for a second migration — this time to refactor what should have been refactored on the first pass — collapses. The team moves on, the technical debt compounds, and the cost line keeps climbing until someone in finance draws a chart.
That's why so many organizations end up moving workloads back. Repatriation is rarely a wholesale exit from public cloud; it's a selective correction of the workloads that should never have been rehosted. The document that would have prevented the mess is cheaper than the one that documents the retreat.