Google Cloud to STACKIT migration checklist

The demo estate and what the run decided

Ten resources became nine units: the subscription is folded into its topic. Confidence is MEDIUM on every unit, because the source declares google 8.4.0 without a lock file. The run was made on 4 November 2026.

1. Discovery

• Scan result is complete

  Open assessment.json and read summary.source_status and source_validation. COMPLETE with built-in checks passed means every file was read; a missing module or an unreadable file shows up here, not later.

• Provider version is pinned

  Commit .terraform.lock.hcl and run again. An unpinned provider caps every unit at MEDIUM confidence, as the demo run states for all nine.

• What Terraform does not know is listed

  Resources created in the console, organisation policies and shared networks managed elsewhere are not in the scan. migration/technical-sequencing.md states plainly that a name, address or certificate outside the scanned source is not seen. Write down who owns each gap.

• Stateful units are named

  migration/data-movement.md lists them: two in the demo, the database and the bucket, both with the mechanism marked unknown.

2. Design

• The target region is answered

  inputs-template.yaml holds one request that blocks the draft: target.region. Answer it first, because the region-dependent requests are asked again for the region you choose.

• Every class is reviewed

  engineering/architect-report.md carries the review queue. In the demo: one DIRECT, six RECONFIGURE, two REPLATFORM, none REDESIGN or BLOCKED. Anything REDESIGN needs its own design page, not a ticket.

• Critical settings have an owner

  decisions.json groups them: six units and fifteen critical settings in the demo. Assign each to a role; execution/manual/actions.md already proposes owners.

• The landing zone exists

  migration/landing-zone-requirements.md states what the organisation and project must provide before the first apply, and lists the values you supply. Create the project first.

Evidence: a Cloud SQL instance, checked

From the same run. Left: the instance as the input declares it. Right: the PostgreSQL Flex block the engine wrote; the review comments above it in the file are left out here. The checks in the data phase below start from this block.

resource "google_sql_database_instance" "core" {
  name             = "core-pg"
  region           = "europe-west3"
  database_version = "POSTGRES_15"

  settings {
    tier    = "db-custom-2-7680"
    disk_size = 100
  }
}

resource "stackit_postgresflex_instance" "core" {
  project_id = var.project_id
  name       = "core-pg"
  version    = "15"
  flavor_id  = "2.16"
  storage = {
    class = var.postgresflex_storage_class
    size  = 100
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.core_allowed_cidrs
  }
  retention_days = 32
}

• Flavor from the catalogue

  2.16 is the smallest single-node flavor that covers the source tier of 2 vCPU and 7.5 GiB.

• Access list instead of a network

  The source states no authorized networks; the STACKIT instance is reached through core_allowed_cidrs, which has no default and which you fill with client prefixes.

• Retention is a floor, not a copy

  The source retention is not visible statically, so 32 days, the STACKIT minimum, is drafted.

3. Build

• Every variable without a default has a value

  In the demo: project_id, batch_image_id, batch_machine_type, batch_boot_volume_size_gb, core_allowed_cidrs, postgresflex_storage_class and three RabbitMQ values (plan name, version, allowed CIDRs). terraform/variables.tf describes each.

• NOT CARRIED lines are read

  The demo shows 26 source properties checked, 20 carried or explained, 6 named NOT CARRIED and none unaccounted. Search terraform/ for the words and decide each, for example the service account's display name.

• Machine types are chosen on load

  The draft leaves the flavor to batch_machine_type. STACKIT's general purpose family pairs 4 vCPU with 16 GB (g2i.4); pick from measured use.

• Secrets are recreated by hand

  The run drafts a Secrets Manager instance, not the secret. Create the key in it, set its value from your vault, and grant access to the service account.

4. Data

• A mechanism is chosen per stateful unit

  State the size, the change rate, the tolerated downtime and the recovery point for the database and the bucket. The run lists the data class, recovery point and downtime as not provided and the size as not in the source; no plan is sound without them.

• Database backup and restore are tested

  The draft schedules a daily backup at 02:00. Backups are kept 32 to 90 days, and a point-in-time restore creates a cloned instance. Practise one restore before cutover.

• Bucket versions are decided

  The bucket has versioning on, and the run flags it. Decide whether old object versions move or are left behind, and use an S3-compatible tool such as rclone for the copy.

• Messaging clients are scheduled

  Pub/Sub publishers and subscribers change to AMQP. The draft creates the RabbitMQ instance only; exchanges and queues are created by hand.

5. Cutover

• Waves match your dependencies

  migration/technical-sequencing.md orders the demo in three waves: seven units, then the subnetwork, then the instance. It is a starting point, not a schedule.

• Names and addresses outside the scan are listed

  The run states that it found no cutover facts for DNS or certificates, and adds that this does not mean none exist. List every name that points into the estate.

• Rollback is written down

  Each manual step in execution/manual/actions.md says the plan does not know how to undo it. Whoever carries out the step records the undo.

• Egress and DNS resolution are proven

  network.tf flags private egress as unproven for the subnet, and notes that Google's resolver answers internal names that STACKIT's default name servers do not.

6. After

• The checks are ticked

  execution/verify/checks.md lists a check before and after each step, such as whether a variable has a value and whether a resource exists in state.

• The assessment is run again

  After you change variables or answer requests, run it again on the same output folder: the draft is regenerated, and the earlier run moves to a previous-<run id> subfolder (or is removed with --replace), so you can compare the two.

• Access is reviewed

  Roles are assigned to the new service account by a person. Google advises against basic roles in production; give the account the least that works.

• The source is retired after a quiet period

  Delete Google resources, keys and service accounts only when nothing has called them for an agreed time, and keep an export.

Questions teams ask about the checklist

Sources

• STACKIT: Object Storage
• STACKIT: Service accounts
• STACKIT: Server machine types
• Google Cloud: IAM roles overview