Cloud migration estimates usually miss by a wide margin, and almost never because of hourly rates. They miss because the work was scoped from a diagram instead of the estate. This is what actually drives the number, and how to sequence a migration so it does not spiral — the substance behind our cloud architecture and migration service.
Why cloud migration budgets get it wrong
A migration plan built from an architecture diagram assumes the estate matches the diagram. It rarely does: undocumented services, hand-configured servers, cron jobs nobody remembers and integrations that only one person understands. The estimate is accurate for the system people describe and wrong for the system that exists.
Cost driver 1 — application inventory and dependencies
- Every application, service, scheduled job and script, including the ones with no owner.
- The dependency graph between them — what calls what, and what breaks if a piece moves.
- The undocumented integrations that turn a simple move into a coordination project.
Cost driver 2 — data gravity and egress
Data is the heaviest thing you move and the most expensive to keep moving. Large datasets take real time and money to transfer, and once in the cloud, moving data out or between regions carries egress charges that surprise teams who planned for compute only.
Data gravity also dictates sequencing: systems whose data cannot move cheaply must either move last or be refactored to reduce the volume that crosses boundaries.
Cost driver 3 — rehost, replatform or refactor
The single largest cost lever is how much you change while you move. "Rehost" (lift and shift) is fastest but leaves you paying for cloud hardware with none of the benefits. "Refactor" unlocks elasticity and managed services but multiplies effort and risk. "Replatform" sits between them, trading a targeted amount of change for a targeted amount of value.
The mistake is choosing one strategy for the whole estate. The right answer is per application, driven by business value and technical debt, not a single company-wide policy.
Cost driver 4 — identity, networking and security
Identity and networking are where migrations stall. Rebuilding IAM, federation, VPNs, DNS, firewall rules and certificate chains is unglamorous, sequenced work that is easy to underestimate and impossible to skip. Getting identity wrong does not delay a migration — it stops it.
Cost driver 5 — the ongoing bill (FinOps)
Migration cost is a one-time number; the cloud bill is not. Without tagging, rightsizing, reserved capacity and cost visibility, the new environment drifts toward expensive idle capacity within months. Budget for FinOps from day one, not as a clean-up later.
How to sequence a migration
Sequence in waves by dependency and value: start with a low-risk, self-contained application to prove the pattern, then move dependents in order once the identity and network foundations are in place. Prototype the riskiest migration before committing the whole programme — prove the hard case in weeks, not after signing a two-year plan.
Treat the first wave as evidence, not just delivery: its real cost and duration calibrate every estimate that follows.
Key takeaways
- Migration estimates miss because they are scoped from diagrams, not the real estate — inventory and dependencies come first.
- The biggest cost lever is how much you change while you move; choose rehost, replatform or refactor per application.
- Sequence migrations in dependency-ordered waves, prototype the riskiest case, and budget for ongoing cloud cost from day one.
Related services
Founder & CEO
Yashwant DanielYashwant Daniel writes on compliance and trust engineering, custom software delivery and applied AI at Solvstrat — covering how regulated and mid-market teams build systems that hold up under audit, scale and scrutiny.
LinkedIn