Migration is not modernization
An estate can be entirely in the cloud and entirely unchanged. Lift-and-shift moves the workload and the constraint together. The infrastructure bill relocates from capital to operating expenditure, and the organization moves at the same speed it did before.
This is not an argument against migration. It is an argument for being precise about what migration is expected to produce.
The decisions that actually matter
- Landing zone and identity, designed first. Network segmentation and access model are extremely expensive to retrofit once workloads are running.
- A per-application decision. Re-host, re-platform, re-architect or retire — decided by the value of the application and its rate of change, not by a program-wide default.
- Delivery pipelines before scale. If deploying a change is still a scheduled event, the cloud has not yet altered anything the business can feel.
- Consumption governance from day one. Cost discipline introduced after the first surprising invoice is remediation, not architecture.
If the deployment cycle has not shortened, the migration has not yet delivered its main benefit.
Cloud as the foundation for data and AI
Data platforms and AI workloads make demands that traditional application estates do not: elastic compute for irregular jobs, storage that scales without renegotiation, and controlled access to sensitive data across environments.
Enterprises that treat cloud as an infrastructure program in isolation frequently discover, two years later, that the landing zone they built cannot accommodate the data platform they now need.
Resilience that has been tested
Availability targets are commitments, not descriptions. The difference is whether recovery has been rehearsed. A failover path that has never been executed is an assumption with a number attached to it.