When 37signals walked away from AWS, it wasn't a marketing stunt. The lesson isn't that the cloud is a mistake. It's that a migration decided on vibes and rushed to completion tends to be the migration that gets reversed two years later.
Most of the pain traces back to what didn't happen before the first workload moved. A pre-migration checklist isn't paperwork. It's the document that decides whether the project ships or stalls, and it's where cloud migrations usually go wrong when teams skip it. The myths below are the ones that keep showing up in post-mortems.
Myth: Lift-and-Shift Counts as a Migration Strategy
Rehosting a virtual machine into a cloud provider is a move, not a strategy. The workload lands in a more expensive environment, keeps its old assumptions about storage and networking, and inherits none of the elasticity that made the cloud attractive in the first place.
A real plan picks a disposition per workload before anything moves. Microsoft's Cloud Adoption Framework calls this the 7 Rs — rehost, replatform, refactor, rearchitect, rebuild, replace, retain — and the choice is workload-by-workload, not a company-wide mandate.
Some things belong on managed services. Some things belong in a container. A few things belong exactly where they are, and moving them is the mistake.
Myth: The New Bill Will Look Like the Old One, Only Cheaper
On-prem bills are boring. They arrive monthly, they don't change much, and finance has learned to ignore them. Cloud bills behave differently, and the surprises come from a short, predictable list:
- Egress and cross-region transfer. Data that used to sit still now moves, and every hop has a price. A backup pattern that cost nothing on-prem can dominate the monthly invoice.
- Over-provisioned instances. Teams size cloud VMs off the old hardware spec sheet instead of measured load, and pay for headroom they never touch.
- Idle non-prod. Dev, staging, and QA environments run 24/7 because nobody wrote the schedule to turn them off.
- Managed-service premiums. Swapping a self-managed database for a managed one is often the right call, but the sticker price is not the same conversation as the license you used to pay.
Build the forecast off measured load, not off the hardware you happen to own. If the pre-migration model can't explain the first three months of the new bill within a reasonable margin, the model isn't done.
Myth: Identity and Access Can Get Sorted After Cutover
Identity is the thing teams promise to clean up in phase two. Phase two never arrives. What arrives is a production environment full of over-scoped roles, service accounts nobody owns, and a break-glass admin that half the team knows the password to.
The pre-migration checklist has to name the identity provider, the role model, the naming convention for service accounts, and the rotation policy for anything that holds a credential. It also has to name an owner for each of those things. Auditors ask who owns the role. "The cloud team" is not an answer that survives a serious review.
Myth: Discovery Is a Spreadsheet You Fill In Once
Discovery is where migrations quietly go wrong. A team lists the applications, counts the VMs, and calls it done. The dependencies between those applications — the shared database, the batch job that runs at 2 a.m., the internal API three other teams rely on — never make it onto the list, and they're what breaks on cutover night.
AWS's own migration guidance splits the work into assess, mobilize, and migrate for a reason: the assess phase is where the readiness review, the TCO analysis, and the dependency map get built. Skipping it doesn't save time. It moves the same work to the worst possible moment, which is the middle of a cutover.
Myth: A Runbook Is the Same Thing as a Plan
A runbook says what to do on cutover night. A plan says why the workload is moving at all, what "done" looks like, who owns the environment afterward, what the rollback criteria are, and what the first ninety days of operation will cost. Those are different documents, and the runbook can't stand in for the other one.
Before anything moves, the plan should answer, in writing: which disposition each workload got and why; the identity and access model; the network and data-egress design; the monitoring, backup, and DR posture on day one; the FinOps guardrails; and the ownership map for everything that now runs somewhere new. A migration without those answers on paper isn't ready to run — it's only ready to be scheduled.
