Cloud migration: sequencing a move that does not break the business

Start with an inventory you actually trust

Before choosing a target platform, establish what is running, what it talks to, and who depends on it. Server lists are usually incomplete; network flow data and application owners fill the gaps.

Capture measured resource usage over a representative period, not the specification of the hardware it happens to sit on today. Most physical estates are heavily over-provisioned, and migrating the specification instead of the workload is the fastest way to overspend in the cloud.

• Application-to-server mapping with a named business owner for each.
• Inbound and outbound dependencies, including scheduled jobs and integrations.
• Measured CPU, memory, IOPS and bandwidth across a full business cycle.
• Licensing constraints, data-residency requirements and contractual obligations.

Choose a migration strategy per workload, not per estate

Different applications warrant different treatment. Some can be lifted and shifted as virtual machines. Some should be replaced with a managed service. Some are best rebuilt, and a few should simply be retired — decommissioning what nobody uses is often the highest-return item in the whole programme.

Deciding this per workload keeps the programme honest: it prevents a single 'modernise everything' mandate from stalling on the least important system in the estate.

• Rehost — fastest path, minimal change, carries existing inefficiency with it.
• Replatform — same application, managed database or runtime underneath.
• Refactor — justified when the application is strategic and the current design blocks growth.
• Retire or replace — the cheapest migration is the one you do not perform.

Plan in waves, with the low-risk wave first

Group workloads into waves that can move together because they share dependencies. The first wave should be genuinely low-risk — internal tooling, test environments — so the team validates the network path, identity integration, backup and monitoring before anything customer-facing moves.

Each wave needs entry and exit criteria in writing: what must be true before it starts, and what must be proven before it is signed off.

• Wave 0: connectivity, identity, DNS, backup and monitoring foundations.
• Wave 1: non-critical internal workloads that exercise the full process.
• Later waves: grouped by dependency cluster, most critical last.
• Every wave: a defined rollback point and an agreed decision deadline within the window.

Cutover mechanics

Cutovers succeed when the data has already been synchronising for days and the window is only used to stop writes, finish the delta, repoint traffic and validate. Anything else — a full copy inside the window, first-time configuration, untested DNS changes — is how a two-hour outage becomes a two-day one.

Lower DNS time-to-live values well in advance, keep the source system intact but read-only after the switch, and define exactly who declares success.

• Pre-seed data and run continuous replication before the window.
• Reduce DNS TTLs days ahead so traffic redirection is fast and reversible.
• Run a scripted validation checklist, including a real user transaction.
• Keep the source recoverable until sign-off, not until the next maintenance window.

The costs that appear after go-live

Compute is the visible cost. Egress bandwidth, inter-zone traffic, snapshot retention, backup storage and forgotten test environments are the ones that erode the business case quietly over the following quarter.

Tag resources from the first deployment, set budget alerts before the first invoice, and schedule a right-sizing review once you have real usage data — the workload's actual profile after migration is rarely the one you estimated.

• Tag every resource by owner and environment on creation.
• Budget alerts configured before the first billing cycle closes.
• Right-sizing review at 30 and 90 days against measured usage.
• Explicit lifecycle rules for snapshots, logs and backup retention.