It's one of the first questions that comes up when an organisation starts planning a cloud migration, and it's one of the hardest to answer honestly without knowing more.
The truthful answer is: it depends. But that's not a particularly useful thing to tell someone who's trying to plan a programme, secure budget, or set expectations with a board. So this post tries to be more specific: about what drives migration timelines, what a realistic range looks like, and where the time actually goes.
The Spectrum of Migration Complexity
Cloud migrations don't have a standard size. At one end, a small organisation with a handful of applications, clean architecture, and a well-understood environment might complete a migration in two to three months. At the other end, a large enterprise with hundreds of applications, legacy systems, complex interdependencies, and multiple internal stakeholders might be running a migration programme for two or three years.
Most organisations sit somewhere in the middle. A business with ten to thirty applications, a mix of modern and legacy infrastructure, and modest organisational complexity should typically plan for somewhere between six and eighteen months from serious planning to full migration.
That range is wide, but the factors that drive it are fairly consistent.
What Actually Takes the Time
Discovery and Assessment
Before any application moves, you need to know what you're moving. This means inventorying your current environment: every application, every server, every database, every integration, every dependency. It means understanding which applications are business-critical, which could be retired, and which require architectural changes before they can move.
Discovery is routinely underestimated. It's not glamorous work, and there's always pressure to start migrating things rather than documenting them. But discovery done poorly produces surprises mid-migration: undocumented dependencies that break in the new environment, applications that turn out to be more complex than assumed, integrations that nobody remembered existed.
For a mid-sized environment, a thorough discovery and assessment phase typically takes four to eight weeks. Skipping or compressing it doesn't save time; it creates problems that cost more time later.
Planning and Architecture Design
Once you know what you have, you need to decide what you're doing with it. Which applications migrate in which order? Which get replatformed? Which get refactored? What does the target architecture look like? How do you handle connectivity, security, identity, and monitoring in the new environment?
This phase often involves multiple stakeholders: engineering, security, finance, and business owners for critical applications. Getting alignment takes time, particularly in larger organisations.
The Migration Itself
The actual migration, moving applications, data, and infrastructure to AWS, is typically the most visible part of the programme, but it's rarely where most of the time goes. Well-planned migrations move at a reasonable pace. Poorly planned ones stall on problems that should have been identified earlier.
Migrations almost always proceed in waves: a small number of lower-risk applications first, to validate the approach and build team confidence, followed by progressively more complex workloads. Running multiple workstreams in parallel can compress this phase significantly if you have the team capacity.
Testing and Validation
Every migrated application needs to be tested in the new environment before production traffic moves to it. This requires time, planning, and cooperation from the teams who own and use those applications. It's also a phase that gets compressed under project pressure, which is where post-migration problems tend to originate.
Cutover and Decommission
The cutover from old infrastructure to new is rarely a single event. For critical applications it's typically a gradual transition: run both environments in parallel, shift traffic progressively, monitor closely, maintain the ability to roll back. Once the new environment is stable, old infrastructure is decommissioned.
Decommission is often slower than people expect. Old infrastructure tends to have undocumented dependencies, and teams are naturally cautious about turning things off permanently.
What Speeds a Migration Up
Clear executive sponsorship. Migrations that have active board or leadership support move faster than those that don't. Decisions get made, resources get allocated, and blockers get resolved.
Dedicated resource. Migrations run alongside normal operational responsibilities almost always take longer than planned. If your team is expected to migrate the infrastructure and keep the lights on, one of those will suffer.
Good documentation. Organisations that already have reasonable documentation of their environments, even basic, have a meaningful head start. Those starting from a blank sheet spend more time in discovery.
A competent external partner. An experienced migration partner brings methodology, tooling, and knowledge of what goes wrong and how to prevent it. They also bring capacity that the internal team may not have.
Realistic Expectations by Scale
These are planning estimates, not guarantees. Actual timelines depend heavily on the factors above.
The Question Beneath the Question
When someone asks how long a migration takes, they're often really asking: is this worth the disruption? Is it manageable? Can we do this without derailing everything else?
The honest answer is that a well-planned migration is disruptive in a controlled way. There will be peaks of activity, periods of parallel running, and moments that require focused attention from people who have other priorities. But a migration that's been properly scoped, resourced, and planned should not be an uncontrolled crisis. The organisations that experience migrations that way are usually the ones that skipped the planning phase.