The cloud migration checklist for the applications nobody wants to touch

Inventory, dependency mapping and the integrations nobody documented

The workloads that stall a migration have no documentation: the file share nobody owns, the job moving a CSV between two finance systems at 02:00, the SOAP endpoint a supplier still calls. Configuration management shows what is installed, not what is calling what.

Hunt the integrations that never reach a diagram: nightly file transfers, database links between applications never meant to talk, hard-coded IP addresses, licences checked against a host name or MAC address, and jobs left behind by someone who moved on.

Discovery is a data exercise, not an interview round. AWS puts portfolio discovery first in its migration approach, and its Application Discovery Service collects utilisation and dependency data from on-premises estates.

Govern each phase by the evidence it produces rather than a status colour. Google Cloud frames migration as stages that start with assessment and a foundation build; the exit criteria below stop the next phase starting on an assumption.

The landing zone has to exist before the first workload

The landing zone is the governed multi-account environment workloads deploy into, and AWS treats it as a distinct early step. It starts with account structure: separate accounts per environment and business unit, plus a log archive account production credentials cannot write to.

Network topology is the long-lead item: address ranges that will not overlap anything you intend to connect, DNS that resolves both ways during the transition, and private connectivity to your data centres, which is a telco procurement rather than a console setting.

Identity and privileged access come next, because they decide whether engineers use the new environment or route around it: federate the directory, define how admin access is granted and logged, and decide who holds a break-glass account.

Then two things that are cheap to build and expensive to retrofit: guardrails expressed as policy rather than as a review meeting, and a tagging schema finance can turn into a cost allocation line. Azure's Cloud Adoption Framework splits a platform landing zone, which carries shared connectivity and identity, from the application zones that use it.

One disposition per application, and the ones that should not move

Give every application exactly one disposition and record who agreed to it. Retain is a real answer, not a way to defer the question, but a retained application still needs a modernisation or cost target, or the estate keeps the licence and the hardware.

Some applications should stay: workloads with a hard latency budget to a machine on a factory floor, software whose licence is tied to physical cores or a named host, and anything bound to a hardware appliance or to mainframe batch the business depends on. Those get retention plus targeted work, such as a modern interface on the front, reporting moved off, and a smaller core left behind.

Rehosting is the fast path and the one that lands you with the same estate on a monthly bill. Replatforming, which substitutes a managed component for a self-managed one, is where the durable saving sits for applications nobody wants to rewrite. Refactoring belongs to the few where the business case is about the code.

Data gravity, the migration window and paying for egress once

Data gravity is the tendency of services to accumulate around the data rather than the reverse, so the dataset sets the timetable, not the application count. Measure volume, daily change rate and acceptable downtime before choosing a mechanism: a copy that outlasts the downtime needs replication or delta sync on top of it.

Bandwidth is the constraint, not cloud capacity, and a direct-connect circuit is a telco order with a lead time, sized against the change rate. For very large one-off transfers, appliances such as AWS Snowball exist because the network path is the limit.

Egress is where the budget leaks. Providers generally do not charge to bring data in and do charge when it leaves, so copying to the cloud, testing and pulling a full copy back pays for the same data twice.

Cutover and rollback, and the database problem

Stateless services cut over cleanly because rollback is a DNS change or a load-balancer weight. Stateful ones do not. A database cutover is close to one-way: once the target accepts writes the source is behind, and a rollback discards every transaction written after the switch.

The workable pattern is a freeze window with agreed start and end, a delta catch-up, a query proving row counts and control totals match, and a named person who decides whether to proceed. A read-only period is cheaper than a rollback: stop the writes, validate, then point the application at the target.

Build the rollback path for the parts that can have one, leave the source intact until the first month-end has passed on the target, and write down in advance what makes a cutover abort.

The cost lines the business case leaves out

Infrastructure run rate is the smallest number in a migration business case. Dual running is the largest omission: both estates are live and billable for the whole transition, which runs longer than planned. Support is second, because the vendor contract and your on-call rota do not stop on the day the workloads move.

Then the partner: assessment, landing zone build and migration factory are separate line items. Training is the line most often assumed away, and the transfer cost of the migration lands on the network budget unless the project claims it. Put all of it in the same table as the savings, dated by quarter, or the business case is a forecast of one line.

The first ninety days after the workloads move

The first bill after cutover is the most expensive one and it is not the steady state. Right-size against the utilisation the workloads now show, check that any commitment or reservation still matches the estate, and watch storage tiers and snapshots, which both grow quietly.

Then decommission: backup jobs duplicating cloud-native backups, monitoring agents reporting on hosts that no longer exist, DR environments built for a data centre that is no longer primary, and the legacy DR licence renewing on its old date.

Review at day thirty and day ninety against what the business case promised: run rate, decommissioned inventory, and applications still marked retained. If the retained list has not moved, the programme has stopped and the cost has not.