Guide · Cloud
A cloud migration playbook for enterprises, from assessment to cut-over
A migration is a sequence of decisions, most of which are made before any server moves. This playbook sets out the phases, the choice of region and data residency, and the practices that make the cut-over weekend uneventful.
The purpose of a playbook
Enterprises rarely migrate once. They migrate a first system, learn from it, then migrate the next ten. A playbook captures what was learned so that the second wave is faster and safer than the first: how systems are assessed, what the landing zone looks like, how a cut-over is run and what “done” means. This guide is the one we use as a starting point with customers; it should be adapted to your organization rather than followed literally.
Two principles run through it. First, migrate the business function rather than the server: the question is how an application and its data continue to serve users, rather than how a virtual machine is copied. Second, keep every step reversible until the moment it is deliberately made permanent.
The Phases
Each phase ends with a decision the steering committee can recognize. Phases overlap across waves: wave two is assessed while wave one migrates.
- 1
Assess
Inventory every application with its owner, dependencies, data classification, integrations, licensing and current infrastructure. Group the applications into waves by dependency and risk. Decide a disposition for each: rehost (move as is), replatform (small changes such as a managed database), refactor (containerize or re-architect), replace (SaaS) or retire. Output: a wave plan with dispositions and the first business case.
- 2
Plan
For wave one, design the target architecture, the network path from your premises, identity (SSO for people, roles for workloads), the data migration method and the cut-over pattern per application. Write the acceptance criteria at this stage: which tests, which users, which reports must agree. Output: a design per application and a runbook skeleton.
- 3
Build the landing zone
Create the account structure, networking, identity, logging, security baselines, backup and cost controls as code before any workload arrives. This is the foundation every later wave stands on, so it is worth building properly once. Output: a Terraform-managed environment that passes its own compliance checks.
- 4
Migrate in waves
Move non-production first, then production, one wave at a time. Replicate data continuously where the pattern requires it, run the acceptance tests in the target against real data, and fix what breaks before anyone else is affected. Output: a target environment that has passed acceptance with the old system still live.
- 5
Cut over
Run the rehearsed runbook: freeze changes, complete the final data synchronization, switch traffic, verify, and announce. Keep the source environment untouched and ready for rollback for an agreed period. Output: production running in the target, with the rollback decision point explicitly passed.
- 6
Optimize
After stabilization, end-size what was over-provisioned for safety, move eligible workloads to managed services or containers, apply commitment pricing where usage is predictable, and decommission the source. Output: a run-cost baseline and the lessons fed back into the playbook for the next wave.
Region selection and data residency
The choice of region comes first. An in-country region, where one exists, offers multiple Availability Zones for resilience and low latency to local users. The AWS Asia Pacific (Bangkok) Region (ap-southeast-7) is one example: it gives organizations with users in Thailand a choice that did not exist for most of the cloud era, instead of serving the country from Singapore. For latency-sensitive systems and for organizations whose policies or regulators prefer data to stay in the country, an in-country region is the default starting point.
Two cautions apply. Newer regions do not launch with every service; check the regional service list for each managed service in the design before committing, and prepare a fallback (a different service, or a different region for that component). Residency is also a policy decision before it is a technical one: personal-data protection law such as the PDPA permits cross-border transfer under conditions, and sector regulators, in financial services for example, may have their own expectations. Write down which data categories must stay in-country and which may be replicated abroad for disaster recovery, and have the legal and compliance teams confirm it. Then encode it as region restrictions in the organization’s policies, so that a misplaced resource is prevented rather than discovered.
Disaster recovery deserves the same clarity. In-region, multiple Availability Zones protect against a facility failure. For protection against a regional event, decide whether a second region is acceptable for backups or standby, which region that should be, and what recovery time and recovery point the business will fund.
Terraform: the landing zone as code
Everything in the landing zone that can be defined as code should be: accounts and organizational policies, networks and routing, identity and roles, logging and audit trails, encryption keys, backup policies, budgets and alerts. Terraform is our tool of choice because it is declarative, provider-agnostic and reviewable in the same pull-request flow as application code.
A few practices keep it manageable. Store state remotely with locking, one state per environment and per logical component, so that a mistake in one place cannot corrupt another. Build small, well-named modules for the things created repeatedly (a service with its container definition, load balancer rule, IAM role and log group) and version them. Tag every resource with owner, environment, application and cost center from a single tagging module, because cost control later depends on it. Run a plan on every change, require review, and apply from a pipeline rather than from a laptop. Detect drift on a schedule and treat manual console changes as incidents to be reconciled rather than as the new normal.
The result is that the environment for wave two is a pull request rather than a project.
Cut-over patterns compared
Choose a pattern per application rather than per program. Downtime tolerance, data volume and the way traffic reaches the system decide which pattern fits.
| Pattern | How it works | Best for | Downtime and rollback |
|---|---|---|---|
| Big-bang (offline) | Stop the source, copy data, start the target, switch DNS or endpoints. | Small systems, batch workloads, internal tools with a maintenance window. | Downtime equals copy time. Rollback is simple: point back to the untouched source. |
| Replicate, then switch | Continuous database replication to the target (for example with a managed replication service) while the source stays live; final sync and switch at cut-over. | Databases and ERPs where a long outage is unacceptable but a short one is tolerable. | Minutes of downtime. Rollback requires reverse replication or accepting data loss since the switch; decide this in advance. |
| Blue-green | Target environment fully built and tested beside the source; traffic switched at the load balancer or DNS in one step. | Stateless and web-tier workloads; applications whose data layer has already moved. | Near zero. Rollback is the same switch in reverse, as long as the data layer is shared or synchronized. |
| Canary / weighted | A small share of traffic (by weight, region or user group) sent to the target, increased as confidence grows. | Customer-facing applications with many users; detecting issues before everyone sees them. | None by design. Rollback is lowering the weight. Requires session handling and data consistency across both sides. |
| Strangler (incremental) | Route one function at a time to new services in the target; the legacy system shrinks until retired. | Large monoliths being refactored; multi-year modernization programs. | None per step. Rollback is per function. Slowest overall, lowest risk per change. |
Rehearsing the rollback
Every runbook has a rollback section; few teams have executed it. Rehearse the full cut-over at least once in non-production with the same people, the same checklist and a clock, then rehearse the rollback. Define the go/no-go criteria before the day (which tests must pass, which stakeholders must confirm, by what time) and name the single person who makes the call. Set the point of no return explicitly: the moment after which new transactions exist only in the target and rolling back means reconciling data by hand.
During the real cut-over, communicate on a schedule rather than when something happens: a status message every thirty minutes, even when it reports that the work is on track, keeps the business calm and the team focused. Afterwards, hold a short review while the details are fresh and update the playbook.
Cost control from day one
Cloud bills grow by default and fall only when someone owns them. Build these controls in before the first production workload.
- Budgets with alerts per account and per application, visible to the application owner as well as to finance.
- Mandatory tags enforced by policy, so all spend is attributable.
- Non-production environments scheduled off outside working hours, or built on demand from Terraform.
- Right-sizing reviews a month after each wave, because migrations are sized for safety rather than for efficiency.
- Commitment pricing (savings plans or reserved capacity) only after usage is stable and understood.
- Storage lifecycle rules: logs, backups and snapshots move to cheaper tiers and expire on a schedule.
- Managed services and containers where the operational saving is real; re-architecting is not a precondition for lower cost.
- A monthly cost review with the same rigor as the availability review.
A second opinion on your wave plan
Share your wave plan and we will tell you what we would do differently. Our cloud and infrastructure team builds Terraform-managed AWS environments and runs migrations for enterprises, including into the AWS Asia Pacific (Bangkok) Region.