A step by step checklist for moving Indonesian enterprise workloads to Google Cloud, from assessment and landing zone to cutover and ongoing support.
A cloud migration goes wrong when teams start moving servers before they have a plan. The work that matters happens earlier: understanding what you have, building a safe place to land it, and choosing the right approach for each workload. Here is the checklist we use with Indonesian enterprises.
Assess before you move
You cannot plan a migration for systems you have not mapped.
- Inventory every application, its dependencies, and its data volumes.
- Group workloads by business criticality and by how tightly they are coupled.
- Flag anything with data residency requirements, since these usually anchor to the Jakarta region.
- Estimate a landing cost on Google Cloud so budget conversations start with real numbers.
Build the landing zone
The landing zone is the foundation every workload sits on. Get it right once and every later migration is faster.
- Set up your organization, folders, and projects to match how teams and environments are actually structured.
- Define network topology, VPCs, and connectivity back to on-premises or other clouds.
- Apply IAM, org policies, and guardrails from the start, not after workloads arrive.
- Turn on centralized logging, monitoring, and Budget Alerts before the first server lands.
Choose an approach per workload
There is no single right migration path. Decide workload by workload.
- Lift and shift suits stable applications you want off the data center quickly, with little code change.
- Modernize when an application is worth the investment, for example moving it to GKE for autoscaling and easier operations, or swapping a self-managed database for Cloud SQL.
- Replatform sits in between: keep the app mostly as is, but drop managed services underneath it to cut operational load.
A common pattern is lift and shift first to hit a data center exit date, then modernize the workloads that will benefit most once they are running on Google Cloud.
Cut over with a safety net
The cutover is where risk concentrates, so plan it carefully.
- Migrate a low-risk workload first to validate the landing zone and the runbook.
- Sync data ahead of time and rehearse the switch so downtime is known, not guessed.
- Keep a rollback path until the new environment has run clean for an agreed period.
- Confirm monitoring and alerts fire correctly on the new stack before you declare done.
Plan for after go-live
Migration is the start of running on Google Cloud, not the finish. Decide who operates the platform day to day, how incidents are handled, and how spend is reviewed each month. Many Indonesian teams pair internal ownership with managed support so they get local-language response and Google Cloud expertise without hiring an entire platform team. Settle this before cutover, and the weeks after go-live stay calm.