Cloud migrations rarely fail because the target platform cannot run the workload. They stall because something nobody knew about surfaces halfway through: a nightly batch job that writes to a shared drive, a licence tied to physical cores, or an integration that only one person remembers configuring.
The fix is not more speed. It is a sequence that surfaces those surprises early, when they are cheap to handle. This is the checklist we follow for moves to AWS and Azure, whether the starting point is an on-premises data center, a co-location rack, or another cloud.
1. Build an inventory you can trust
Start with what actually runs, not what the architecture diagram says runs. Discovery tools such as AWS Application Discovery Service and Azure Migrate collect server specifications, utilization, and network connections. They are a starting point, not an answer.
Pair the tooling with short interviews of the people who operate each system. Ask what breaks when the system is down, what it talks to, when it is busiest, and who signs off on changes. Those answers turn a server list into a dependency map.
- Every workload, with its owner, environment, and business criticality.
- Inbound and outbound dependencies, including file shares, scheduled jobs, and third-party APIs.
- Data volumes, growth rate, and how much downtime the business can accept.
- Licences, support contracts, and anything tied to specific hardware.
2. Choose a path for each workload
Not everything should move the same way, and some things should not move at all. AWS describes the options as the "7 Rs". They are a useful vocabulary on any cloud:
- Retire: switch off systems nobody needs. Every migration finds some.
- Retain: keep a workload where it is for now, with a reason and a review date.
- Rehost: move it largely unchanged. Fast, but it carries existing inefficiencies with it.
- Relocate: move a virtualized estate to the cloud version of the same platform.
- Repurchase: replace it with a SaaS product.
- Replatform: make targeted changes, such as moving a self-managed database to a managed service.
- Refactor: redesign the workload to use cloud-native services where the business case supports it.
Write the reason for each decision down. Six months later, when someone asks why a system was rehosted rather than refactored, the answer should be in a document, not in someone's memory.
3. Build the landing zone before the first workload
A landing zone is the foundation every workload lands on: account or subscription structure, identity, networking, logging, and the guardrails that stop insecure configurations from being deployed. Building it first is slower in week one and much faster by month three.
Define it as code, with Terraform or the cloud's native tooling, so it can be reviewed, versioned, and recreated. Centralize logs from day one. Retrofitting audit logging after workloads are live is one of the most common and most expensive gaps in cloud estates.
- Separate accounts or subscriptions for production, non-production, and shared services.
- Single sign-on with your existing identity provider, and no shared administrator credentials.
- Network design that covers how the cloud connects back to anything that stays on-premises.
- Centralized logging and alerting, with retention that meets your audit and regulatory needs.
4. Plan the work in waves
Group workloads into waves based on the dependency map, not on organizational charts. Systems that talk to each other constantly should move together, or the latency between old and new environments will become the problem you spend the migration debugging.
Make the first wave deliberately low-risk: a few internal applications with forgiving owners. Its job is to test the landing zone, the runbook, and the team's rhythm. Expect it to teach you something, and update the plan before the second wave.
5. Rehearse the cutover
The cutover is where migrations earn or lose trust. Treat it as a rehearsed operation with a written runbook, named owners for each step, and explicit go/no-go criteria agreed with the business beforehand.
For systems with significant data, replicate continuously and cut over at a planned point rather than copying everything during the outage window. Lower DNS time-to-live values days in advance so traffic moves quickly when you switch. Above all, test the rollback path. A rollback plan that has never been run is a hope, not a plan.
- A runbook with timings, owners, and verification steps for each stage.
- Go/no-go criteria agreed before the window opens.
- Data validation that compares source and target, not just row counts.
- A rehearsed rollback, with the point of no return clearly marked.
6. Optimize after the move
A workload that has just been rehosted is usually over-provisioned, because it was sized for hardware bought years ago. Review utilization after a few weeks of real traffic, right-size instances, and apply consistent tagging so every resource has an owner and a cost center.
Then decommission the source environment. Running old and new in parallel indefinitely is how migrations double costs instead of reducing them.
A note on compliance
If the workloads process personal data of people in the Philippines, the Data Privacy Act of 2012 applies wherever the data is hosted. Regulated sectors, such as banking, insurance, and healthcare, often have additional rules on outsourcing and cloud use. Confirm those requirements with your compliance team before choosing regions and designing data flows, not after.
The short version
- Inventory what actually runs, including the jobs and integrations nobody documented.
- Decide and record a path for every workload.
- Build and codify the landing zone first.
- Move in dependency-based waves, starting small.
- Rehearse cutovers and test rollback.
- Right-size, tag, and decommission the old environment.
If you are planning a move and want an independent view of where the risks are, our Cloud Readiness & Migration Assessment produces a workload inventory, a recommended path for each workload, and a phased plan with rollback considerations.
Filed under Cloud