Cloud migration readiness: what to settle before you move

Lifting a workload into a cloud platform is, in isolation, a well-understood engineering task. What derails migrations is everything around it: a dependency nobody documented, a workload that was refactored when it should have been rehosted, a network design settled in week two that has to be unpicked in month six, and a cutover with no agreed trigger for turning back.

Almost all of that is decided before any workload moves. The organisations that migrate calmly are the ones that spent the first few weeks producing four artefacts: a dependency map they trust, a per-workload migration pattern with the reasoning recorded, a landing zone design signed off by whoever owns security and networking, and a written cutover runbook with explicit rollback triggers.

None of those require the target platform to be chosen first, and all of them retain their value if the platform changes. This is the readiness work that sits ahead of the cloud migration itself.

The single most common cause of schedule slippage is a dependency discovered during cutover rather than during planning: a scheduled job on a forgotten server, a hard-coded IP address in a partner's firewall rule, a reporting tool reading directly from a production database, a licence bound to a MAC address.

A practical way to surface them

1. Start from observed traffic, not documentation. Collect flow logs, connection tables and firewall logs over a period long enough to include month-end and any quarterly cycle. Documentation reflects intent; traffic reflects reality.
2. Add the scheduled and the seasonal. Cron jobs, batch windows, backup agents, monitoring probes and annual processes will not appear in a two-week capture. Inventory the schedulers explicitly.
3. Interview around the map. Show the observed graph to application owners and ask what is missing. People recognise a gap in a diagram far more reliably than they recall a list from memory.
4. Include the non-technical. Vendor contracts, licence portability, data residency obligations, IP allow-lists held by third parties and integrations owned by other companies all constrain the move.
5. Group into move-groups. Components that chat constantly across a low-latency link generally have to move together. The output you want is not a list of servers but a set of independently movable bundles, each with its own risk profile.

Treat the map as a living artefact owned by a named person and updated as discoveries land. A dependency map that was accurate at kickoff and never revised is a source of false confidence.

“We're refactoring everything” and “we're lifting and shifting everything” are both expensive positions. The right unit of decision is the workload, and the reasoning should be written down so it can be revisited.

Rehost

Move as-is. Right when the application is stable, the team has no appetite to change it, a datacentre exit has a date attached, or the application is a candidate for replacement within a couple of years. Accept that cloud-native savings will be limited until a later pass.

Replatform

Keep the application, change what surrounds it — a managed database instead of a self-managed one, a managed load balancer, containerised runtime, managed backups. This is usually the best return per unit of risk, because it removes operational toil without touching business logic.

Refactor

Justified when the architecture itself is the constraint: scaling limits that hurt the business, release cycles that cannot keep up, or licence costs structurally tied to the current design. Refactoring during a migration doubles the number of variables in play, so it deserves its own plan and its own timeline.

And the honest fourth and fifth options

• Replace with a suitable product where the capability is genuinely commodity.
• Retain or retire. Every estate contains workloads with no active users. Finding them is one of the more reliable savings in the whole exercise.

Criteria to apply

• Business criticality and tolerable downtime.
• Rate of change — how often does this application actually get released?
• Licensing model and its portability to the target platform.
• Data gravity: volume, sensitivity, residency and how tightly coupled it is.
• Whether the team that owns it has the capacity to absorb change right now.

A landing zone is the foundation the workloads land on: account or subscription structure, network topology, identity, guardrails, logging and cost boundaries. These choices are cheap to make before the first workload arrives and painful to change once a hundred have.

• Account and subscription structure. Separation by environment and by business unit gives you blast-radius containment and clean cost attribution. Retrofitting it means moving resources between accounts.
• Network and address planning. Allocate non-overlapping ranges with room for growth and for acquisitions. Overlapping ranges are the classic cause of painful connectivity workarounds years later.
• Identity and access. Federate to your existing directory, define roles rather than individual grants, and remove standing administrative access from the outset.
• Connectivity to what stays. Very few estates move entirely. Decide how hybrid connectivity, DNS resolution and certificate issuance work across both sides before the first cutover.
• Tagging and cost boundaries. A mandatory tagging standard enforced by policy at creation time is trivial now and a lengthy clean-up project later.
• Logging, backup and recovery. Central log destinations, retention periods and tested restore procedures belong in the foundation, not in a hardening phase after go-live.
• Everything as code. If the landing zone is built by hand, the second environment will not match the first, and neither will be reproducible under pressure.

Build a cost model against this design before committing. Compute is the easy part; egress charges, inter-zone traffic, managed service premiums, backup storage and licence changes are where estimates usually go wrong.

The cutover is the only part of the migration that users experience. It should be the least improvised part of the project, and it should be rehearsed against a copy of production before it is performed on production.

Parallel running

Where the workload allows, run both environments together and compare outputs before switching authority. For read-heavy systems this is straightforward. For anything transactional, decide early which side owns writes, how data is reconciled, and how long the dual-running window lasts — indefinite parallel running quietly doubles both cost and operational load.

Rollback triggers

Define, before the window opens, the specific conditions that mean you revert: error rate above a threshold, data reconciliation mismatch, a business function unavailable beyond an agreed number of minutes. Name the person authorised to call it, and give them explicit permission to do so without escalation. Ambiguity here is what turns a two-hour setback into a weekend outage.

What a usable runbook contains

• A timed sequence of steps with the named owner and expected duration of each.
• Prerequisites and a go/no-go checkpoint before the point of no return.
• DNS and TTL changes staged in advance, with propagation time accounted for.
• Data synchronisation and final delta steps, with reconciliation checks.
• Verification tests — technical health plus a short business smoke test.
• Rollback steps in the same detail as the forward steps, and rehearsed.
• Communication plan: who is told what, when, and through which channel.
• A defined hypercare period with elevated support cover and a daily review.

Sequence the schedule so the first cutover is a low-criticality workload. The purpose of the first move is to find the flaws in the runbook while the cost of finding them is low. Steady-state operation afterwards — patching, monitoring, backup verification — is a different discipline again, and worth assigning explicitly to a managed services team if there is no capacity in-house.

Before the first production workload moves, all of the following should be true. If any is not, the honest answer is that the programme is not ready — and saying so early is considerably cheaper than discovering it mid-cutover.

1. Dependency map complete and validated by application owners, including scheduled jobs, third-party integrations and licensing constraints, grouped into move-groups.
2. Migration pattern assigned per workload with the reasoning recorded, and retire/retain decisions taken.
3. Cost model built covering compute, storage, egress, managed service premiums, backup and licensing, with the run-rate compared honestly against today's total cost.
4. Landing zone designed and deployed as code, with identity, network addressing, guardrails, tagging and logging signed off by security.
5. Backup and restore tested in the target environment — a restore actually performed, not a backup job merely configured.
6. Rollback plan written and rehearsed for the first move-group, with named decision authority and defined triggers.
7. Monitoring and alerting in place before cutover, not after, with someone rostered to receive the alerts.
8. Team trained and roles assigned for operating the new environment, including who holds administrative access and who is on call during hypercare.
9. Business stakeholders briefed on the window, the expected impact and the escalation path.