An AWS-to-GCP Migration Checklist

The mapping is the easy part

An AWS-to-GCP migration looks deceptively simple on a whiteboard: EC2 becomes Compute Engine, S3 becomes Cloud Storage, RDS becomes Cloud SQL, draw the arrows and ship. The arrows are real, but the work that actually consumes your timeline lives in the gaps the mapping hides — identity models that do not translate, networking defaults that differ, and data transfers that take longer than anyone budgeted. This checklist is the order we work through migrations so the surprises happen in planning rather than at cutover.

Inventory before you architect

You cannot migrate what you have not catalogued. Before touching GCP, build an honest inventory of the AWS estate:

• Every running service, its size, and its actual utilisation — not the size someone provisioned two years ago.
• Data volumes per store, because a quarter-terabyte database and a forty-terabyte data lake demand completely different transfer strategies.
• The dependency graph: what talks to what, which calls cross availability zones, and which external services hold a hardcoded endpoint that will break the moment an address changes.

This inventory is also your first cost-saving opportunity. A migration is the rare moment when right-sizing is expected, so map to what the workload needs on GCP, not to a like-for-like copy of AWS waste.

Identity and networking are where lift-and-shift breaks

The two areas that reliably bite teams are IAM and the network, because the mental models genuinely differ. AWS IAM policies attach to users, groups, and roles in a way that does not map one-to-one onto GCP's resource-hierarchy-and-role model. Do not translate policies line by line — re-derive the access you actually need from least privilege and grant that. On networking, the VPC concepts rhyme but the defaults do not: subnet behaviour, firewall-rule semantics, and egress paths all differ enough that a copied topology will misbehave in subtle ways.

• Re-model IAM around GCP's hierarchy of organisation, folders, and projects rather than porting AWS roles verbatim.
• Rebuild firewall rules from intent; confirm egress and private-service-access paths explicitly.
• Plan DNS cutover with low TTLs set well in advance so you can roll back in minutes if something is wrong.

Most failed cloud migrations did not fail on compute. They failed on a firewall rule or an IAM grant nobody re-checked.

Move data with a strategy that matches its size

Data migration strategy is dictated by volume and downtime tolerance. Small databases move with a dump and restore inside a maintenance window. Large or zero-downtime systems need replication: stand up the GCP target, replicate continuously until it is caught up, then cut over with a brief freeze. For very large object stores, the network transfer itself can dominate the schedule — measure your real throughput early, because discovering at cutover week that a copy needs nine days is the kind of surprise that derails launches.

Validate, then cut over, then keep the old one warm

Never make cutover the first time the GCP environment runs real traffic. Run the new stack in parallel, replay production-like load against it, and compare behaviour and cost before committing. When you do cut over, keep the AWS environment running long enough to fall back to, and only decommission once the new platform has proven itself across a full business cycle including the monthly and end-of-quarter peaks. The cost of a few extra weeks of parallel running is trivial against the cost of a bad cutover with no way back.

Watch for the costs that do not map

The line items that wreck a migration budget are rarely the compute, which is easy to compare. They are the second-order costs the service mapping never shows. Data egress is the classic ambush: moving data out of AWS is metered, and a large estate can run up a transfer bill that nobody costed because it does not appear on either side's per-hour pricing page. Managed-service equivalents are another gap — a feature bundled into one provider's database may be a separate, separately-billed product on the other, so a like-for-like architecture quietly changes price.

• Estimate egress for the actual data volumes before committing to a transfer plan, not after the invoice lands.
• Compare managed services on delivered capability and total cost, not on the marketing-page label, because the boundaries differ.
• Re-cost the workload at its right-sized GCP shape, since carrying AWS over-provisioning across the wire just relocates the waste.

Migrations rarely blow the budget on compute. They blow it on egress and on a managed service that turned out to be three separately-billed products.

How BSH can help

BSH Technologies runs cloud migrations end to end — inventory and right-sizing, IAM and network re-architecture, data transfer strategy, and parallel-run validation with a real rollback plan. Fluent in both AWS and GCP, we have moved production workloads without the surprises that make migrations infamous. If a move to GCP is on your roadmap, talk to us before the arrows go on the whiteboard, and we will help you plan for the gaps the mapping hides.