Cloud migration projects have a reputation for going over budget and over schedule. Having done eight of them over the past three years, we can confirm: the reputation is earned.
But the overruns usually aren't where you'd expect. The technical work—actually moving systems to AWS or GCP or Azure—is usually the easy part. The hard part is everything else.
What Vendors Tell You
Cloud vendors (and many consulting firms) frame migration as a technical problem. You assess your current systems, design target architectures, and execute the migration. They'll give you a timeline measured in months and a budget measured in infrastructure costs plus labor.
This framing isn't wrong, exactly. But it's incomplete in ways that matter.
What Actually Takes Time
Based on our experience, here's how time actually breaks down in a typical migration:
25% goes to technical assessment and architecture—the part everyone talks about. Understanding what you have, designing where it should go, writing the actual migration code.
30% goes to data migration and validation. Not moving the data, which is relatively easy. Validating that the data moved correctly, handling edge cases, and dealing with the inevitable surprises in data that's accumulated over years.
25% goes to organizational work. Getting buy-in from teams who have to change their workflows. Training engineers on new tools. Coordinating cutover schedules with business stakeholders. Managing the period where you're running both systems in parallel.
20% goes to operational readiness. Building monitoring for new infrastructure. Creating runbooks for problems you've never seen before. Getting on-call engineers comfortable with systems they didn't build.
The first 25% is what gets scoped. The other 75% is what causes overruns.
Data Migration Is Always Worse Than You Think
Every migration we've done has had data surprises. Not small ones. Fundamental ones that required rethinking the approach.
One client had customer records with addresses that didn't match any standard format—because they'd been entered by hand over 15 years, with different formats in different eras. The new system expected structured addresses. We spent six weeks building a data cleaning pipeline that wasn't in the original scope.
Another client had a "simple" migration of a MySQL database to RDS. Except the database had grown so large that standard export/import tools would take weeks. We had to build a custom streaming replication system. That added two months.
Budget 2-3x whatever you think data migration will take.
The Parallel Running Period Is Expensive
For any critical system, you're going to run old and new infrastructure in parallel for a while. This sounds reasonable until you realize what it means.
Every change has to be made in two places. Every bug fix has to be verified in two environments. Every deployment takes twice as long. On-call engineers need to understand both systems.
We've seen parallel running periods stretch from "a few weeks" to six months. The longer it runs, the more expensive it gets—not because of infrastructure costs, but because of the cognitive overhead on engineering teams.
Set a hard deadline for parallel running and treat it as immovable.
Organizational Work Can't Be Parallelized
Technical work can often be parallelized. You can have one team working on database migration while another works on compute migration.
Organizational work can't. You can't run three training sessions simultaneously if the same engineers need to attend all three. You can't get buy-in from stakeholders faster by assigning more people to the task.
This creates a scheduling problem that most project plans underestimate. Even if the technical work could be done in 4 months, the organizational work might force it to stretch to 6.
Specific Recommendations
Based on our experience:
Double your timeline estimate for anything involving data migration. Assume the parallel running period will be twice as long as planned. Invest in training before the migration, not after. Identify one engineer on each affected team who will become the local expert on the new infrastructure—and give them time to actually learn it.
Don't try to improve things during the migration. Lift and shift first. Optimize later. Every improvement you try to make simultaneously adds risk and extends timelines.
The Honest Assessment
Cloud migrations are worth doing. The benefits—scalability, reliability, reduced ops burden—are real. But they're expensive in time and organizational attention.
If someone tells you a major migration will take 6 months, assume 12-18 is more realistic. If they tell you it's mostly technical work, assume they haven't done many migrations.
The companies that do this well are the ones that go in with realistic expectations and a willingness to invest in the non-technical work that actually determines success.