Google Cloud to STACKIT migration

Separate what moves from what must be rebuilt

Google Cloud estates often pair portable workloads with deeply managed data services. Treating both the same makes a plan wrong from the first line, so each resource gets its own treatment and reason.

1. Reads your Terraform

   Google Cloud resources, modules and dependencies from Terraform and OpenTofu root modules.

2. Network treated as design

   Dedicated readers cover routes, firewall rules, identity and placement. Firewall policies and Cloud NAT change their model on STACKIT, and the plan says how.

3. Drafts the target

   STACKIT Terraform drafts, target architecture, execution sequence and a register of open choices for your architects.

Where your services go

Typical outcomes from the StackToIT knowledge base. The treatment of each resource depends on its configuration, and the report states the reason.

What it gives the business

1. See the data platform work early

   BigQuery, Spanner and Bigtable have no direct counterpart and are marked for redesign, so the largest items are in the plan before the budget is set.

2. Reuse your container investment

   GKE workloads target STACKIT Kubernetes Engine, and Cloud Run services move to SKE or Cloud Foundry as containers.

3. Choose waves on evidence

   Treatment and dependencies per resource show which systems can move first and which depend on a design decision.

Your architects review each draft before anything is applied. For databases from a private PostgreSQL or SQL Server source, set the network access scope in the draft explicitly.