Most cloud migration estimates are wrong. Not marginally wrong — wrong by a factor of two or three. The organisations that deliver migrations successfully are not the ones with the most aggressive timelines. They are the ones that planned honestly for what they would find.
The documentation problem
Every migration project begins with an inventory. What applications do we have, what do they depend on, and what do they talk to? The answer, in almost every organisation that has been running on-premise infrastructure for more than five years, is: we do not know exactly.
The documentation exists. It was accurate in 2019. Since then, three teams have made changes without updating the records, two applications have been decommissioned (but their databases are still running), and one critical internal service is documented under a name that nobody uses anymore.
The first two weeks of a migration are almost always spent discovering this. Not moving workloads. Not provisioning AWS environments. Mapping what actually exists, which is different from what the documentation says exists.
What a realistic timeline actually looks like
A typical migration for a 50-person SaaS company running 15 to 20 applications on ageing on-premise infrastructure will take between four and nine months, depending on application complexity and how much refactoring is required before lift.
Breaking that down:
- Weeks 1–4: Discovery. Actual application inventory, dependency mapping, traffic analysis, and identifying undocumented integrations.
- Weeks 5–8: Landing zone. Setting up the AWS account structure, networking (Amazon VPC, subnets, peering), identity (IAM Identity Center, IAM policies), and security baseline (GuardDuty, policies, logging).
- Weeks 9–16: Wave 1 migration. The lowest-complexity applications. Learn the process, validate the environment, and build the team's confidence before moving anything critical.
- Weeks 17+: Remaining waves, including the complex stateful applications, database migrations, and any refactoring required for cloud-native operation.
What good project scoping looks like
A credible migration partner will spend the first engagement scoping honestly what needs to move, in what order, and what needs to change before it can move. If the first conversation is a proposal for a fixed-price migration with a six-week timeline, the proposal is not based on your environment — it is based on a template.
The dependency mapping problem
Dependencies are the second place migrations go wrong. Most application teams know what their application calls. They do not always know what calls their application, or what their application's data store is used by.
A database that was supposed to serve one application turns out to be queried by three. An internal API that was scheduled for deprecation two years ago still receives 40,000 requests a day from an application the original team no longer maintains. These discoveries do not stop migrations. They do reset timelines.
The tools for dependency mapping — AWS Migration Hub, network flow analysis, and application performance monitoring during a pre-migration assessment period — exist and work. Using them requires time that is almost never in the original project budget, which is why it is almost never done until the migration is in trouble.
Three things to do before your first workload moves
If you are planning a cloud migration, or have one that is already underway and running behind, the most useful interventions are the same regardless of stage.
One: Fund discovery as a standalone phase. Not as the first two weeks of a migration. As a separate, explicitly scoped engagement with its own deliverables: an accurate application inventory, a dependency map, a migration wave plan, and a risk register.
Two: Build your landing zone before any workload moves. The AWS environment structure — account structure, networking, identity, security baseline, and monitoring — needs to be in place and tested before the first application arrives. Migrations that build the landing zone and migrate workloads simultaneously consistently take longer and produce harder-to-manage environments.
Three: Start with the least complex workloads. The purpose of the first wave is not to move the most applications. It is to learn the process in production, validate the environment, and build confidence before moving anything you cannot afford to get wrong.
Cloud migration is engineering work, not a procurement decision. The organisations that navigate it well treat it as a project with honest scope, real timelines, and a partner who will tell them what the work actually involves before they sign anything.