What does a cloud migration plan actually need to cover?
Published: Oct 20, 2026 · Last updated: Oct 20, 2026
A cloud migration plan is the order you move systems in, the downtime each move needs, and the way back if a move fails. Strategy decks cover which cloud and which pattern, but the plan that ships covers dependencies, waves, cutover windows and rollback.
If you are reading this, you probably have a system that is getting harder to keep alive. The servers are ageing, the support contract renews soon, or the hosting bill keeps climbing while nobody can say what half the machines do. You have been asked to move it to the cloud, and you need a plan the business will sign off.
This article gives you that plan: how to map what depends on what, group systems into migration waves, choose what goes first, agree downtime with the people who own the revenue, and spot the problems that usually stall a cloud migration before they stall yours.
The order you move things in matters more than the cloud you move them to.
Why do cloud migrations stall halfway through?
Cloud migrations stall because the plan was built from an inventory, not from a dependency map. An inventory tells you which servers exist. It does not tell you that the reporting job on server 14 reads straight from the billing database every night at 2 a.m., and breaks the moment billing moves.
Ageing systems collect these hidden links over years. A shared file drop, a hardcoded IP address in a config file, a cron job written by someone who left, a database link between two schemas, an internal DNS name that only resolves on the office network. None of them show up in your configuration database. All of them show up on cutover night.
Three other causes sit next to hidden dependencies:
Licensing. Some enterprise databases and middleware are licensed per physical core or per named host. Moving them to virtual cloud instances can change what you owe or break the licence terms, and procurement often finds out after the move.
Data transfer time. Teams estimate migration in hours of engineering, not hours of copying. A 10 TB database over a 100 Mbps link takes more than nine days to copy once, before you count the changes that pile up meanwhile.
No rollback plan. If the only plan is forward, every small failure becomes a crisis call at 4 a.m., and the team learns to delay the next wave.
Notice that none of these are cloud problems. They are gaps in what you know about your current system, which is why the first phase of a good plan happens entirely on the old infrastructure.
What does it cost you to get the sequence wrong?
Getting the order wrong costs you time first, then trust. A failed cutover usually means a rollback under pressure, an outage longer than the window you promised, and a business that hesitates to approve the next window.
The quiet cost is the hybrid trap. Half your systems run in the cloud, half still run on-premise, and the two talk across a VPN link that adds latency to every call. You now pay for both environments, run two sets of monitoring and keep two kinds of knowledge alive in one team. Migrations can sit in that state for a long time because nobody wants to own the next risky wave.
Other consequences to plan around before you start:
Slow users. Chatty services split across the link get slower, and users notice before your dashboards do.
Data drift. When two copies of a database both accept writes during a messy cutover, reconciling them is slow manual work.
Compliance gaps. Logs, backups and access controls that were never rebuilt in the new environment are audit findings waiting to happen.
Team fatigue. Engineers burn out on repeated weekend cutovers that keep getting rolled back.
Every one of these is avoidable with planning work done before a single server moves. The rest of this article is that work.
Who does not need a migration plan this detailed?
If your product already runs as a handful of containers with a managed database, you probably do not need wave planning. You need a quiet weekend, a tested backup and a DNS change.
The same is true if you have one application, one database and no integrations with other internal systems. Copy it, test it, switch traffic, and keep the old server running for a couple of weeks as your rollback. A capable in-house engineer can do that with the cloud provider's own tools, such as AWS Application Migration Service, Azure Migrate or Google Cloud's Migrate to Virtual Machines.
The plan below is for the harder case: ten or more systems, a database that several of them share, integrations nobody fully documented, and a business that cannot simply switch off for a day.
How do you map dependencies before you move anything?
Map dependencies by watching real traffic, not by asking people. Interviews tell you what teams think talks to what. Network flow data tells you what actually does.
Work through it in this order:
1. Capture traffic for at least one full business cycle. Use VPC or firewall flow logs, AWS Application Discovery Service, Azure Migrate's dependency analysis, or scheduled netstat snapshots. The cycle must include month-end, because batch jobs and finance reports hide there.
2. Search configs for addresses. Grep every config file, script and connection string for hardcoded IPs and hostnames. Each hit is a connection that breaks when the address changes.
3. List scheduled jobs. Cron, Windows Task Scheduler, SQL Agent jobs, ETL tools. Write down what each one reads and writes.
4. List outside parties. Payment gateways, banks, partners and anyone who allowlisted your current IP address. They need notice to update their firewall rules, and some need weeks of it.
5. Draw the graph. Systems are boxes, connections are lines. Mark each line with how often it is called and how much delay it tolerates.
That last detail decides your waves. Two systems that call each other hundreds of times per user request cannot live on opposite sides of a VPN link. Two systems that exchange one file a night can.
If the map shows a tangle you cannot cleanly cut, look at which modernization option fits each system before you move it. Carrying the tangle into the cloud only moves the problem to a new address.
Which system should go first, and how do you group the rest into waves?
Move a low-risk system with few dependencies first, but make it real enough to test your whole process. The first wave is a rehearsal for your landing zone, network, monitoring and cutover runbook. It is not the moment to move your most valuable system.
Good first-wave candidates: an internal tool, a reporting service that reads a copy of the data, a staging environment, or a stateless web front end. Bad first-wave candidates: the shared database, the billing system, or anything with a partner on the far end of an allowlisted IP.
Then group everything else with these rules:
If two systems are tightly coupled, they move in the same wave. Splitting them creates the latency problem above.
If several systems share one database, the database decides the wave. Either it moves with all of its consumers, or you replicate it so the cloud copy stays in sync until the last consumer moves.
If a system has expiring hardware or an ending support contract, pull it forward. The deadline is real and the business will back you.
If a system is due for replacement within a year, move it last or retire it. Migrating something you are about to switch off is wasted effort.
Keep each wave small enough to roll back inside one window. If you cannot undo it in the time you have, it is too big.
The trade-off is calendar time against risk. Fewer, larger waves finish sooner on paper, but each failure hurts more. More, smaller waves take longer and teach your team something every time. For an ageing system with patchy documentation, smaller waves almost always win.
Before wave one, build the landing zone properly: accounts, networking, identity, logging, backups and a deployment pipeline. Our guide to CI/CD pipelines covers the pipeline side. Skip this and every wave rebuilds the basics by hand.
How do you set a downtime window the business will accept?
Start from what the business can tolerate, then design the cutover to fit it. Ask the owner of each system two questions: how long can this be unavailable, and how much recent data can we afford to lose? Those answers are your recovery time and recovery point targets, and they decide the technique.
Match the technique to the answer:
A few hours of downtime is fine: back up, restore in the cloud and switch. Simplest to run and easiest to rehearse.
Under an hour: replicate data to the cloud continuously ahead of time, then stop writes, let the final changes sync and switch traffic. Native database replication or AWS Database Migration Service handles the sync.
Minutes or close to zero: run both environments in parallel and shift traffic gradually with weighted DNS or a load balancer. This needs an application that tolerates two live copies, which many ageing systems do not.
Then do the arithmetic the business never sees. Time the final sync in a rehearsal, add the smoke tests, add the DNS change, and add the time to roll back if a test fails. If the total does not fit the window, change the technique, not the promise.
Lower DNS TTL values to around 60 seconds a few days before cutover so traffic really moves when you switch. Book the window in the quietest period your own usage data shows, and give support, sales and outside partners exact start and end times.
Write a go or no-go checklist for each wave with named sign-offs: the system owner, the person running the cutover, and whoever owns customer communication. Agree the rollback trigger in advance, for example error rates above the normal baseline for 15 minutes. That removes the argument at 3 a.m.
Where cloud migrations usually stall, and how to spot it early
Most stalls show warning signs weeks before cutover. Here is what to check, and why each item earns its place:
Licences reviewed by procurement, in writing. Per-core and per-host licences can change in cost or legality on cloud hardware, and that finding can freeze a wave overnight.
Data transfer measured, not estimated. Copy a real sample over the real link. If the full copy takes days, start replication early or use a physical transfer device such as AWS Snowball or Azure Data Box.
Rollback tested in a rehearsal. An untested rollback is a hope. Keep the old system intact and able to take traffic until the new one has run cleanly through a full business cycle.
Every hardcoded address has an owner. Each one is a broken connection on cutover night unless someone has switched it to a DNS name first.
Monitoring live before traffic moves. If you cannot see errors and latency in the new environment, you will hear about problems from customers.
A named owner for every wave. Waves without an owner drift, and drifting waves create the hybrid trap.
If an outside team is doing the work, ask them before they start:
How will you discover dependencies, and with which tools?
What is the rollback plan for each wave, and when will you test it?
How did you measure data transfer time?
Who signs off go or no-go, and what triggers a rollback?
Who owns the cloud accounts and infrastructure code when you finish?
The answer to the last one should be you. At Geminate Solutions, clients own 100% of the code and IP, including the infrastructure-as-code that builds their environment. Our cloud and DevOps team has run systems that handle 10M+ requests per minute in production (exam platform), and that work shapes how we plan cutovers for systems that cannot afford a long outage.
Get your migration plan reviewed before wave one
If you have a system list, a rough sequence or only a deadline, send it to us. We will review it for free and send back the dependencies we think you are missing, a suggested first wave, and the stall risks we see in your licensing, data volume and rollback approach.
We sign an NDA before we talk, and we reply within 24 hours. If a system should be modernised rather than moved as it is, we will tell you, and point you to the options in our legacy system modernization guide.
