Cloud migrations rarely fail because the target platform was wrong. They fail because something nobody had written down (a scheduled job, a hard-coded IP, a licence tied to a MAC address) surfaced at two in the morning on cutover night, with the business waiting.
The work that prevents that happens weeks earlier, and it is unglamorous. Here are the four questions worth answering before a single workload moves.
1. What is actually running, and what talks to it?
Every organisation has an inventory it believes in and an estate it actually runs. The gap between them is where migrations break. A dependency map is not a diagram somebody drew in 2021; it is built from live traffic, scheduled tasks, and connection strings.
What to look for specifically:
- Scheduled work. Cron jobs, Windows scheduled tasks, and database agents. These are invisible in an application inventory and catastrophic when they silently stop.
- Hard-coded addresses. IPs and hostnames baked into configuration files, firewall rules, and partner integrations you do not control.
- Licensing. Anything bound to hardware, a MAC address, or a fixed host. It needs a vendor conversation, and vendors are not fast.
- The one person who knows. If a system has exactly one person who understands it, that is a project risk, not a staffing detail.
2. What is this workload worth once it is running?
Lift-and-shift has a reputation for being expensive, and it often is, because a virtual machine sized for a 2019 on-premise peak keeps that size in the cloud, where you now pay for it by the hour.
Attach a monthly run-cost to each option before deciding. Rehosting a workload unchanged, replatforming it onto managed services, and refactoring it properly produce three different numbers, and the right answer differs per workload. Some systems deserve the engineering. Others deserve to be retired, and a migration is an unusually good moment to find out which.
3. What does the rollback look like?
The question is not whether the cutover will work. It is what happens in the twenty minutes after it does not.
A rollback plan that has only been written down is a hope. A rollback that has been executed in a rehearsal (in a staging environment that genuinely resembles production) is a plan. The rehearsal also produces the timings, which is how you size the maintenance window honestly instead of optimistically.
4. Who owns it on the Monday after?
Migration projects end. The estate does not. Monitoring, alerting, patching, backup verification, and cost review all need an owner with a name, and that ownership should be agreed before go-live rather than discovered afterwards.
This is also where migrations quietly lose their business case. The savings modelled during planning evaporate within a quarter if nobody is watching right-sizing and reserved capacity. Thirty days of deliberate tuning after cutover typically protects more value than any decision made during the move itself.
The shape of a migration that works
Discover, decide, rehearse, cut over, optimise. Two weeks of genuine discovery, a disposition per workload with costs attached, a full dry run with a tested rollback, the real move in an agreed window, then a month of tuning and a handover your own team can operate.
It is slower on paper than the version that skips the rehearsal. It is considerably faster than the version that skips the rehearsal and then has to explain the outage.
Delisys Technologies runs its own products on Azure at production scale, and migrates client estates from on-premise, AWS, and GCP. If you would like the dependency map before committing to anything else, that is where we start, and you keep it whether or not you migrate with us.
