The timeline in almost every cloud migration proposal I've seen has been wrong. Not slightly wrong — off by a factor of two to three. The kick-off deck says 6 months. Eighteen months later, the migration is still running, the original budget is gone, and the team that was supposed to be building new product features is still lifting and shifting workloads from 2014.
I've been directly involved in, or brought in to rescue, approximately twenty enterprise cloud migrations — across reinsurance, energy, manufacturing, and SaaS. Here is what they actually took, why the estimates fail, and what separates the migrations that finish on time from the ones that don't.
Why Migration Estimates Are Almost Always Wrong
Before the data: the systematic underestimation is not incompetence. It is structural. Every incentive in the pre-migration period pushes toward optimistic timelines.
The vendor or consultant selling the engagement underestimates to win the deal. The internal champion underestimates to get budget approval. The engineering team underestimates because they are assessing the workloads they know well — not the ones they've forgotten about. And the first estimate is made before the discovery phase, which is where the real scope emerges.
The three categories of surprise that eat migration timelines — consistently, across all twenty of my projects:
1. Application inventory is always incomplete. No organisation I have worked with has had an accurate count of the applications that needed to be migrated before we started. The number grows, on average, 40–60% during discovery. A company that thinks it has 30 applications to migrate has 45–50. The ones they forgot are always the most complicated — internal tools, legacy integrations, and that one critical batch job that runs once a month and that only one engineer understands.
2. Data is the actual hard part. Moving compute is solved. Moving data — at scale, with zero data loss, maintaining compliance with GDPR data residency requirements and financial services data retention rules, while keeping the source system live — is the hard part. In nearly every migration I've run, data migration alone consumed more calendar time than was originally allocated to the entire project.
3. Organisational friction compounds technical complexity. Cloud migrations cross team boundaries. The network team controls firewall rules. The DBA team controls database credentials. The compliance team controls what can go to which cloud region. Procurement controls cloud vendor agreements. Each of these becomes a bottleneck at some point during the migration. The technical work is often faster than the approval and coordination work.
The Twenty Migrations: What They Actually Took
I've grouped the twenty migrations by type and size. Names are anonymised; industries noted where relevant.
Small-Scope Migrations (single application or workload)
These are migrations of a discrete, well-understood application — typically a web application, a microservice cluster, or a data warehouse — to a cloud provider, with limited dependencies.
| Project | Industry | Original Estimate | Actual Duration | Overrun Factor | Primary Delay |
|---|---|---|---|---|---|
| SaaS analytics platform | Insurance tech | 3 months | 5 months | 1.7x | Data migration volume underestimated |
| Internal dev tooling stack | Reinsurance | 2 months | 2.5 months | 1.25x | Network peering approvals |
| Web frontend + API | Energy retail | 3 months | 4 months | 1.3x | Security review added mid-project |
| Reporting warehouse | Manufacturing | 4 months | 7 months | 1.75x | Schema complexity; GDPR data residency |
| HR SaaS integration layer | Financial services | 2 months | 5 months | 2.5x | Vendor API changes during migration |
Median overrun: 1.7x. The cleanest migration in this group (the dev tooling) was clean because it had no customer data, no production dependencies, and a single team that owned it entirely.
Mid-Scale Migrations (platform or multi-application, 5–20 workloads)
This is the most common category I work in — a platform or business unit migrating its application portfolio, typically from on-premise data centres or a single-cloud legacy environment to a modern cloud architecture.
| Project | Industry | Original Estimate | Actual Duration | Overrun Factor | Primary Delay |
|---|---|---|---|---|---|
| Claims processing platform | Reinsurance | 8 months | 18 months | 2.25x | Regulatory approval, data sovereignty |
| Customer-facing portal + 8 backend services | Insurance | 6 months | 14 months | 2.3x | Integration testing failures; 3 legacy dependencies discovered |
| Energy trading data platform | Energy | 9 months | 16 months | 1.8x | Real-time data pipeline complexity |
| Manufacturing MES migration | Automotive | 12 months | 22 months | 1.8x | OT/IT integration, vendor dependency |
| B2B SaaS platform lift-and-shift to Azure | SaaS | 5 months | 11 months | 2.2x | Database migration; customer data isolation requirements |
| Internal analytics platform | Financial services | 6 months | 15 months | 2.5x | Data quality issues found during migration |
| IoT telemetry platform | Energy | 8 months | 13 months | 1.6x | Volume scaling issues in target architecture |
Median overrun: 2.2x. The IoT migration ran closest to estimate because the team had done a similar migration 18 months earlier — prior experience is the single best predictor of timeline accuracy.
Large-Scale Migrations (enterprise-wide, data centre exit, or full-estate migration)
These are multi-year programmes migrating an organisation's full technology estate, usually including both core business systems and supporting infrastructure.
| Project | Industry | Original Estimate | Actual Duration | Overrun Factor | Primary Delay |
|---|---|---|---|---|---|
| Full data centre exit | Reinsurance | 18 months | 36 months | 2.0x | 3 unmapped legacy systems; regulatory hold |
| Enterprise cloud transformation | Energy utility | 24 months | 48 months | 2.0x | Organisational change programme required; SAP dependencies |
| On-premise to Azure, 40+ applications | Manufacturing | 18 months | 30 months | 1.7x | Application interdependencies; phased business approval |
| Financial core systems migration | Insurance | 24 months | 60 months | 2.5x | Vendor lock-in; regulator sign-off on each phase |
| Multi-region cloud consolidation | Reinsurance | 12 months | 22 months | 1.8x | Data sovereignty requirements by jurisdiction |
| SaaS platform rebuild + legacy migration | SaaS | 12 months | 20 months | 1.7x | Parallel rebuild; cutover coordination |
| Hybrid cloud programme | Energy | 18 months | 28 months | 1.6x | Network architecture complexity |
| Global infrastructure re-platform | Financial services | 30 months | 54 months | 1.8x | Regulatory engagement in 6 jurisdictions |
Median overrun: 1.85x. The large-scale migrations run closer to 2x as a floor because their complexity exceeds any single team's ability to accurately scope before starting.
The Pattern in the Data
Looking across all twenty, the overrun factor clusters between 1.6x and 2.5x, with a mean of approximately 2.4x. The three migrations that came closest to their original estimates share something: they had all been through a similar migration before, the scope was tightly bounded before the estimate was made, and they had a full-time dedicated programme manager with both technical and organisational authority.
The worst overruns (2.5x and beyond) share different traits: scope expanded during discovery, compliance or regulatory approval added an unpredictable dependency, or the migration uncovered a legacy system that had to be refactored before it could be migrated.
The discovery-first rule
Every migration that finished close to estimate ran a dedicated 4–8 week discovery phase before the timeline was committed. Every migration that badly overran skipped or compressed discovery to start quickly. The pattern is so consistent that I now refuse to give a migration timeline estimate before a discovery phase is complete. The cost of discovery is almost always recovered in avoided overruns within the first 3 months of execution.
What Actually Drives the Variance
After twenty projects, here are the factors that separate on-time migrations from the ones that run 3x over:
Discovery completeness
The single highest-leverage investment in a migration programme. A rigorous discovery phase — 4–8 weeks, application interviews, dependency mapping, data inventory, compliance review — reduces timeline variance more than any other single intervention. It costs €15,000–50,000 upfront and routinely saves 3–6 months of execution time.
Data volume and complexity
Database migrations are reliably underestimated. The specific killers: large tables with complex foreign key graphs, undocumented data transformations embedded in stored procedures, GDPR-constrained data that requires sanitisation before migration, and high-volume event streams that cannot tolerate downtime. If data is involved, add 40% to whatever the data team estimates.
Organisational model
Migrations run by dedicated migration teams with authority to make technical decisions finish faster than migrations run as "a project alongside normal operations." At an absolute minimum, you need a full-time programme manager, a cloud architect with the authority to make binding architectural decisions, and at least 2–3 engineers who are not split across other projects.
Regulatory and compliance dependencies
In regulated industries (financial services, energy, insurance), migrations require regulatory engagement that is almost never reflected in initial timelines. GDPR data residency assessments, financial regulator notifications, and ISO/SOC compliance re-certification for new environments each add weeks to months of calendar time — regardless of how prepared the technical team is.
The "one more thing" discovery problem
In approximately 75% of the migrations I've worked on, the team discovered a critical system or dependency that was not on the original inventory — after the migration was already underway. In three cases, this discovery extended the programme by 6+ months. This is not bad luck. It is the predictable consequence of application inventories that are maintained by humans rather than generated by automated discovery tools.
The business case that doesn't survive contact with reality
Many cloud migrations are justified on a cost-savings business case — typically 20–30% reduction in infrastructure costs over 3 years. When the migration runs 2x over estimate, those savings are deferred by 12–18 months and the business case breaks. If your migration business case depends on realising savings within a fixed timeframe, build the cost of a 2x overrun into your planning. Not because you plan to fail — but because the data says you should.
A Realistic Timeline Framework
Based on the twenty projects, here is what a properly scoped migration timeline actually looks like:
Application inventory (with automated tooling, not just interviews), dependency mapping, data inventory and classification, compliance requirements assessment, target architecture definition. Do not commit a delivery timeline until this phase is complete.
Cloud landing zone build, network architecture, identity and access management setup, security controls, monitoring and logging foundation. This runs partially in parallel with discovery. Underestimated in 17 of 20 projects I've worked on.
Migrate the 2–3 applications that are most straightforward. Not to get quick wins — to validate the migration tooling, runbooks, and cutover process before applying them at scale. The pilot almost always reveals tooling or process gaps that would have caused failures at scale.
Migrate remaining workloads in waves of 4–8 applications, grouped by dependency and business risk. Each wave includes a cutover, a hypercare period, and a decommission of source infrastructure. Timeline per wave: 4–8 weeks.
Cost optimisation (Reserved Instances, right-sizing), security posture hardening, final decommission of source infrastructure. Almost always deprioritised until the end, almost always takes longer than estimated.
The five phases overlap and feed back into each other in practice:
As a rule of thumb: take whatever timeline the team estimates after discovery, and apply a 1.5x buffer before communicating it to the board or executive sponsors. Not because you expect failure — but because the data says this is closer to reality than the original estimate.
The Three Things That Actually Help
After twenty of these, here is what I'd tell someone starting a migration programme today:
Run discovery first. No exceptions. Four to eight weeks before the clock starts on the delivery timeline. The discovery findings will change your estimate, your architecture, and probably your scope. Better to know that before you've committed a deadline.
Assign a dedicated team. A migration run by engineers doing it alongside their normal jobs runs at roughly 40–50% of the speed of a dedicated migration team. The calendar time difference is usually larger than the additional cost of dedicated headcount.
Track against the original inventory. Every migration should have a live tracker showing: total applications in scope, migrated, in-flight, blocked, and discovered-post-kickoff. That last category — things discovered after kickoff — is where schedule risk lives. If it starts growing, the timeline needs to be revised before it becomes a crisis.
If you are planning a cloud migration or are already in one that has started running over, let's talk. I've run migrations from first discovery to final decommission across industries where failure is not an option. Book a 30-minute call and we can assess where the real timeline risk sits in your programme.