Why cloud migrations run long: three systemic reasons
Cloud migrations almost always take longer than planned. Three causes I see consistently, and how to work with them.
Almost every cloud migration project I have observed took longer than initially estimated. Sometimes by half. Sometimes double. Sometimes more. The teams were competent, budgets were allocated, the technology choices were correct.
The technology is not the issue. The issue is three systemic causes that are almost always present - and almost never accounted for in the original plan.
The first cause: hidden dependencies
At the start of a project there is usually a list of systems to migrate. It seems complete. In practice, every system turns out to be connected to others in ways that are not documented.
Application A talks directly to database B, bypassing the official API. Service C reads files from a network folder that physically sits on server D. Reporting system E connects to F every night through a legacy protocol that nobody remembered.
These dependencies are discovered during migration, not before it. Each one is a stop, an analysis, a decision. Multiplied by the number of systems - that is months.
What helps: map dependencies before migration begins. Not from documentation - from actual traffic. Network monitoring tools run for a few weeks will show who is really talking to whom.
The second cause: organisational friction
Cloud migration is a change to the operating model, not just the technical one. Engineering, infrastructure, security, finance, business operations - each has their own requirements, priorities, and pace of decision-making.
A typical scenario: the technical decision is made, the architecture is agreed, and then the project stalls for several weeks because the security team requires an audit of the new configuration. Or finance cannot approve the change in the cost model until the next quarter. Or the business unit is not ready for the system downtime in the proposed maintenance window.
These are not technical problems. They are change management problems that were not anticipated in the plan.
What helps: bring key stakeholders from all affected divisions into planning from the very beginning. Not to approve the technical solution, but so that their constraints and requirements are known before the start, rather than discovered along the way.
The third cause: underestimating legacy
Legacy systems are not just old code. They are systems where years of undocumented business logic has accumulated - logic that exists nowhere except in the code itself. And often, code that nobody on the current team fully understands.
During migration this shows up like this: the system comes up in the cloud and technically runs, but something behaves differently. Investigation reveals that in the old environment there was a setting that compensated for the behaviour of another system. Or there was a dependency on a specific library version. Or the behaviour depended on the server's time zone.
All of this is found during the process, not before it. And each discovery costs time.
What helps: honestly assess how well-understood the legacy systems are. If a system is maintained by one person who knows it better than anyone - that is a migration risk. If there is no documentation - budget time for study before the transfer begins.
How to plan realistically
I do not have a universal correction factor for cloud migrations, because it depends heavily on the specifics. But two rules hold almost universally.
First: any timeline estimate made without dependency mapping and without security and finance involved is not an estimate - it is a hypothesis. Treat it accordingly.
Second: migration does not proceed in a straight line. Build in iterations, rollback points, and milestone reviews. A project that sails off into a long run without intermediate checkpoints is very difficult to stop or correct.