Most cloud migrations that go over budget or over schedule fail for the same reason: an undocumented dependency surfaces mid-cutover, not because the cloud platform itself has a problem. A pre-migration audit that inventories infrastructure, data, licensing, deployment maturity, and cost assumptions before you touch a single workload catches those dependencies while they're still cheap to fix. Skip the audit and you find them during the maintenance window instead.
Infrastructure Inventory and Undocumented Dependencies
Start with a full inventory of what's actually running, not what the architecture diagram says is running. Diagrams go stale within months; production doesn't wait for someone to update Visio. Pull the real list from your hypervisor, cloud console, or CMDB, then cross-check it against:
- Cron jobs and scheduled tasks on hosts nobody has logged into in over a year
- Hardcoded IP addresses in application config, firewall rules, and third-party integrations
- Internal services that talk to each other over a flat network with no service discovery
- Shared file mounts (NFS, SMB) that multiple applications read from or write to
- Background workers, batch jobs, and reporting scripts that run outside the main application path
The dependencies that break migrations are rarely the big, documented ones. They're the reporting script that queries a database directly instead of through an API, the legacy app that assumes it can reach another server on the same subnet, or the certificate that was issued to a specific internal hostname. Budget real time for this step — a week of tracing network flows and interviewing whoever's been at the company longest is cheaper than a rollback.
Data Volume and Downtime Tolerance
Data migration timing depends on two numbers you need before you plan a cutover date: how much data has to move, and how much downtime the business will actually accept. These two numbers often conflict, and finding that out early changes your migration strategy.
Work out:
- Total data volume per system, and how much of it is cold data you could migrate weeks ahead of cutover versus hot data that has to move last
- Your actual transfer throughput, not the theoretical link speed — test it, don't estimate it
- Whether the business tolerates an offline cutover window, or whether you need a replication-based approach (database replication, dual-write, or a sync-then-switch pattern) to hit near-zero downtime
- Who signs off on the downtime window and what other business events (billing runs, quarter close, seasonal peak) it can't overlap with
If the math says a full offline copy would take 30 hours and the business will only accept a 4-hour window, that's not a scheduling problem — it's a signal you need incremental replication, and that changes your migration architecture before you've moved anything.
Licensing That Doesn't Transfer
Software licensing is one of the most common places a migration budget gets blown, because licenses that make sense on owned hardware often don't map cleanly onto cloud consumption models. Audit every license against these questions:
- Is it tied to a physical MAC address, CPU socket count, or hardware fingerprint that won't exist in a VM or container?
- Does the vendor offer a cloud-compatible license, and does it cost more per unit than the on-prem version?
- Are you running under a bring-your-own-license (BYOL) model, and does the cloud provider's marketplace image already include licensing costs you'd be paying twice for?
- Do support contracts explicitly cover the cloud deployment, or does moving the workload silently void support?
Get this in writing from each vendor before migration, not after. A license audit that takes two weeks up front is far less painful than finding out a production database is unlicensed the week it goes live.
Deployment Process Maturity
How you deploy today determines how much manual work the migration will require, and whether the new environment will be maintainable afterward. Be honest about where each application actually sits:
- Fully manual: someone RDPs or SSHs in and copies files or runs scripts by hand
- Scripted but not automated: shell scripts or Ansible playbooks exist, but a person still triggers and watches them
- CI/CD: commits trigger automated build, test, and deploy pipelines with no manual step
Applications with manual deployment processes need that fixed before or during the migration, not after. Moving a manual deployment process to the cloud unchanged just means you now do the same manual work against unfamiliar infrastructure, with no faster to diagnose when something goes wrong. Treat the migration as the forcing function to build a real pipeline for at least your highest-traffic services.
A Realistic Cost Model
Compare current spend to projected cloud spend using real numbers, not vendor calculator defaults. Include:
- Current fully-loaded cost: hardware depreciation, power, cooling, data center space, and the staff time spent on patching and hardware failures
- Projected compute and storage cost at your actual usage pattern, not average or best-case
- Data egress costs — the fee most cost estimates miss, charged every time data leaves the cloud provider's network to your office, another cloud, or end users
- Reserved instance or savings plan commitments, and what you lose if actual usage comes in lower than projected
- The overlap period where you're paying for both old and new infrastructure during migration
Egress in particular catches teams off guard because on-prem environments rarely meter outbound traffic, so nobody has a number to compare against. If your application serves large files, video, or bulk exports, model egress specifically rather than folding it into a generic "networking" line item.
A Rollback Plan for Every Service
Every service on the migration list needs its own rollback plan before it moves, not a single generic "we'll figure it out" plan for the whole project. For each service, document:
- The specific trigger conditions that mean "roll back now" (error rate threshold, data corruption, failed health check) rather than a vague "if something goes wrong"
- How you revert DNS, load balancer, or traffic routing back to the old environment
- Whether data written to the cloud environment during the cutover window needs to be reconciled back to the old system, and who owns that reconciliation
- How long the old environment stays available and untouched as a fallback before it's decommissioned
Services with data written during the cutover window are the hardest to roll back cleanly, because a rollback isn't just a DNS change — it's making sure no data gets lost or duplicated in the switch. Plan those services first and give them the longest fallback window.