GCP Terraform to STACKIT Terraform

One real conversion: Cloud SQL to PostgreSQL Flex

The database of Google Cloud's Dynamic Python Web App, assessed unchanged with a one-line variable file (project_id = "example-project"). On the left the Cloud SQL instance exactly as Google publishes it, on the right the block exactly as StackToIT wrote it in the run. The comments the draft keeps above each block are left out here.

resource "google_sql_database_instance" "postgres" {
  name                = var.random_suffix ? "${var.instance_name}-${random_id.suffix.hex}" : var.instance_name
  database_version    = "POSTGRES_14"
  project             = var.project_id
  region              = var.region
  deletion_protection = false

  settings {
    tier        = "db-custom-2-4096" # 2 CPU, 4GB Memory
    user_labels = var.labels
  }
  depends_on = [module.project_services]

}

resource "stackit_postgresflex_instance" "postgres" {
  project_id = var.project_id
  name       = "postgres"
  version    = "14"
  flavor_id  = "2.4"
  storage = {
    class = var.postgresflex_storage_class
    size  = var.postgres_storage_size
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.postgres_allowed_cidrs
  }
  retention_days = 32
}

• Engine, version and size carried over

  POSTGRES_14 becomes a PostgreSQL Flex instance on version 14. The tier db-custom-2-4096 (2 CPU, 4 GB memory) becomes flavor 2.4, which is 2 vCPU and 4 GiB on a single node in the eu01 catalogue of 18 October 2026.

• Backups and retention

  The source states no backup start time, so the draft uses a default of 02:00 daily (0 2 * * *) and says so. Its backup retention is not visible statically; retention_days is 32, the STACKIT minimum (32 to 90).

• Values to decide become variables

  The source states no disk size, and a Cloud SQL disk grows by itself while a PostgreSQL Flex storage has a fixed size: postgres_storage_size is a variable (5 to 4000 GB) to set after reading the current disk. The storage class and the allowed CIDRs, which limit the instance endpoint by ACL, are variables too.

• Every property accounted for

  Of the 12 meaningful properties on this Cloud SQL unit (instance, database and user), 6 are carried or explained and 6 are named as not carried: the labels, the user password, both names and both ABANDON deletion policies. None is left unaccounted. STACKIT generates the user password, and you create the user and the database with stackit_postgresflex_user and stackit_postgresflex_database.

Second conversion: Cloud Run service to STACKIT Kubernetes Engine

STACKIT has no Cloud Run, so the Django API service becomes a workload on STACKIT Kubernetes Engine. On the left the service exactly as Google publishes it. On the right the Kubernetes manifests StackToIT wrote for it; they run on the cluster stackit_ske_cluster.containers in terraform/kubernetes.tf, which also hosts the migration job.

resource "google_cloud_run_v2_service" "server" {
  name     = var.random_suffix ? "${var.service_name}-${random_id.suffix.hex}" : var.service_name
  location = var.region

  deletion_protection = false

  template {
    service_account = google_service_account.server.email
    containers {
      image = local.server_image
      env {
        name = "DJANGO_ENV"
        value_source {
          secret_key_ref {
            secret  = google_secret_manager_secret.django_settings.secret_id
            version = "latest"
          }
        }
      }
      env {
        name  = "PYTHONPATH"
        value = ""
      }
      env {
        name  = "DJANGO_SETTINGS_MODULE"
        value = "avocano_api.settings"
      }
      # These variables are a standard part of OpenTelemetry SDK configuration.
      # Details are available at
      # https://opentelemetry.io/docs/reference/specification/sdk-environment-variables/#exporter-selection
      env {
        name  = "OTEL_METRICS_EXPORTER"
        value = "none"
      }
      env {
        name  = "OTEL_TRACES_EXPORTER"
        value = "gcp_trace"
      }
      env {
        name  = "OTEL_PYTHON_EXCLUDED_URLS"
        value = "healthy"
      }
      # Supply the custom suffix, if used, to support automated CSRF code in application settings
      env {
        name  = "DEPLOYMENT_SUFFIX"
        value = var.random_suffix ? random_id.suffix.hex : ""
      }
      volume_mounts {
        name       = "cloudsql"
        mount_path = "/cloudsql"
      }
      liveness_probe {
        http_get {
          path = "/healthy"
        }
      }
    }
    labels = var.labels
    volumes {
      name = "cloudsql"
      cloud_sql_instance {
        instances = [google_sql_database_instance.postgres.connection_name]
      }
    }
  }
  traffic {
    percent = 100
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
  }

  depends_on = [
    google_secret_manager_secret_version.django_settings
  ]

  lifecycle {
    ignore_changes = [
      scaling,
    ]
  }
}

apiVersion: v1
kind: ConfigMap
metadata:
  name: server-env
  labels:
    app.kubernetes.io/name: server
data:
  DEPLOYMENT_SUFFIX: "" # fill in: the value is not copied from the source
  DJANGO_SETTINGS_MODULE: "" # fill in: the value is not copied from the source
  OTEL_METRICS_EXPORTER: "" # fill in: the value is not copied from the source
  OTEL_PYTHON_EXCLUDED_URLS: "" # fill in: the value is not copied from the source
  OTEL_TRACES_EXPORTER: "" # fill in: the value is not copied from the source
  PYTHONPATH: "" # fill in: the value is not copied from the source
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  labels:
    app.kubernetes.io/name: server
spec:
  replicas: REQUIRED_SERVER_REPLICAS
  selector:
    matchLabels:
      app.kubernetes.io/name: server
  template:
    metadata:
      labels:
        app.kubernetes.io/name: server
    spec:
      containers:
      - name: container-1
        image: "us-docker.pkg.dev/hsa-public/containers/terraform-python-dynamic-webapp/server:v1.13.4"
        ports:
        - containerPort: 8080
          protocol: TCP
        env:
        - name: PORT
          value: "8080"
        - name: DJANGO_ENV
          valueFrom:
            secretKeyRef:
              name: server-secrets
              key: DJANGO_ENV
        - name: PYTHONPATH
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: PYTHONPATH
        - name: DJANGO_SETTINGS_MODULE
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: DJANGO_SETTINGS_MODULE
        - name: OTEL_METRICS_EXPORTER
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: OTEL_METRICS_EXPORTER
        - name: OTEL_TRACES_EXPORTER
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: OTEL_TRACES_EXPORTER
        - name: OTEL_PYTHON_EXCLUDED_URLS
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: OTEL_PYTHON_EXCLUDED_URLS
        - name: DEPLOYMENT_SUFFIX
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: DEPLOYMENT_SUFFIX
        livenessProbe:
          httpGet:
            path: "/healthy"
            port: 8080
        readinessProbe:
          tcpSocket:
            port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: server
  labels:
    app.kubernetes.io/name: server
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: server
  ports:
  - name: p8080-tcp
    port: 8080
    targetPort: 8080
    protocol: TCP

• Image, port and health check carried over

  The container image and its liveness path /healthy come straight from the service. The source states no port, so the draft uses 8080, the Cloud Run default, and adds a readiness check on that port.

• Secret and environment split

  DJANGO_ENV comes from a Secret Manager secret and becomes a Kubernetes Secret reference, server-secrets, which you create. The five plain variables become the keys of the ConfigMap server-env; the draft does not copy their values, you fill them in.

• One cluster for service and job

  The cluster stackit_ske_cluster.containers has a node pool named workloads. Machine type, minimum and maximum nodes are variables without a default, and the zones default to eu01-1, eu01-2 and eu01-3. The migration job becomes a Kubernetes Job on the same cluster.

• Replica count held, exposure to decide

  The number of pods is a required input, so the apply holds until you set it: 0 for the apply step, then the number the source runs once the data is loaded. The Service is a ClusterIP and exposes nothing yet: an Ingress or a LoadBalancer Service, its certificate and its DNS record are your decision.

• Named as not carried

  The service account of the revision, the labels, the traffic split between revisions, the deletion protection and the Cloud SQL connection volume. The pods run as the default ServiceAccount until you decide the identity, and they reach the database by its network address.

How the conversion works

1. 01

   Resolve the estate

   18 files and the registry module project_services 18.0.0 become one dependency graph: 37 resources, 11 migration units and 29 dependencies, read offline. Five more units depend on variables and are decided when OpenTofu plans.

2. 02

   Decide per resource

   A versioned rule base gives each resource a STACKIT target and a migration class, based on its actual configuration and with a confidence value.

3. 03

   Write STACKIT code

   10 resource blocks in files per domain: data, Kubernetes, messaging, storage, identity and security, plus 13 variables, Kubernetes manifests and the STACKIT provider pinned to 0.121.0. Four units are proposed as modules that stay switched off.

4. 04

   Check and trace

   StackToIT ran its 20 draft checks, and none found a violation. OpenTofu 1.13.1 ran tofu init and tofu validate on the draft and accepted it. Each block carries a trace ID that leads back to its source resource.

What the run reported

Selected lines of the console summary of this run, verbatim.

Source files:           18
Resources scanned:      37  (34 in the root module · 3 inside 1 module call)
Migration units:        11 known-present (11 instances) · 5 conditional
Unit dependencies:      29
Modules:                1 module call (1 external, 0 local): 1 loaded, 0 not downloaded, 0 invalid
Source checks:          Built-in source checks passed — OpenTofu validation of the source did not run (LOCK_FILE)

DIRECT              0  
RECONFIGURE         6  ████████████████ 54%
REPLATFORM          2  █████ 18%
CONTAINERIZE        2  █████ 18%
REDESIGN            0  
MANUAL_REVIEW       1  ██ 9%
BLOCKED             0    (the mapping class BLOCKED, not the execution blockers, which Migration readiness counts)
Confidence  HIGH 0 · MEDIUM 10 · LOW 1

69 source properties checked across 11 generated units: 29 carried or explained, 40 NOT CARRIED, 0 unaccounted — see engineering/architect-report.md.

STACKIT draft (this folder/terraform): 11 units generated · 4 proposed, switched off · 0 need no resource · 1 left for the architect · 13 variables
  StackToIT draft checks: PASSED (20 checks, none found a violation)
  OpenTofu validation: PASSED (tofu init -backend=false and tofu validate accepted the draft; tofu 1.13.1)
tofu validate: STATIC_TERRAFORM_VALIDATION_PASSED — deployment readiness and live target behaviour not verified

Next action   Allow the calls of STACKIT APIs that are not generally available — Owner: Platform Architect · details: index.html

• 37 resources, 11 units, 5 at plan time

  34 resources sit in the root module and 3 inside the registry module. Child resources join the unit they serve, and 8 support resources are read by the units that use them. Five further units exist only if a variable holds when OpenTofu plans; they are assessed too and marked as such.

• 11 of 16 units drafted

  11 units have generated STACKIT resources, written as 10 blocks. 4 are proposed and stay switched off until you decide, and the Firebase project stays with your architect. The draft has 13 variables.

• 69 properties, 0 unaccounted

  29 properties are carried or explained and 40 are named as not carried over, in the file engineering/not-carried.csv. The check covers the 11 generated units.

• A class for every unit

  The run decided 6 RECONFIGURE, 2 REPLATFORM, 2 CONTAINERIZE and 1 MANUAL_REVIEW, and assessment.json gives the reason for each unit.

• The next action has an owner

  The plan has 78 steps. 10 of its 12 automated steps are free of decisions and wait only for values such as project_id. 6 decisions are open; the first, owned by the Platform Architect, is to allow STACKIT APIs that are not generally available. 27 input requests are open.

How the 11 units and the 5 decided at plan time were decided

Classes as the run decided them. The first 11 rows are the units found in the source; the last 5 exist only if a variable holds when OpenTofu plans, and hold on the defaults of this run.

What lands in terraform/

The STACKIT Terraform of this run, organized the way a platform team maintains it.

data.tf

PostgreSQL Flex instance for the Cloud SQL instance

kubernetes.tf

One SKE cluster with a node pool for the Cloud Run service and job

kubernetes/

Manifests for server (ConfigMap, Deployment, Service) and migrate (Job)

messaging.tf

RabbitMQ instance for the Pub/Sub topic

rabbitmq/

Topology file and script for the exchanges and queues, which the provider does not create

storage.tf

Object Storage bucket for the media bucket

identity.tf

The 4 service accounts

security.tf

Secrets Manager instance and the migration user that writes the secrets

proposals.tf, proposals/

8 modules, each behind a switch that is off until you decide

handover/

Preparation notes for the database move, the media copy and cluster access

variables.tf

The 13 values your team sets or confirms, each with a description

terraform.tf

Pinned STACKIT provider

README.md

What the draft holds, the services to enable first, the target security checklist and what is not carried

What comes with the Terraform

The same run writes the material your architects and operators work from.

assessment.json

Per unit: class, confidence, STACKIT target, reason and findings

engineering/not-carried.csv

The 40 properties the draft does not carry, one row each, with the reason

engineering/trace/

One trace file per draft file, from each block back to its source

architecture/

Diagrams of the current and target architecture, network security and data flows

migration/technical-sequencing.md

4 waves computed from the dependencies between units

execution/

The execution package: 24 work packages with 64 manual steps, 2 API steps, a deploy script and a pipeline example

decisions.json

The structured decision record, with 6 decisions to make in this run

financial/

Price lines and coverage: 2 of 8 STACKIT lines priced, no comparison stated

review/

Templates for your answers and target values, which the next run reads

Questions platform teams ask

Sources

• StackToIT example: Google Cloud Dynamic Python Web App, the complete run
• GitHub: GoogleCloudPlatform/terraform-dynamic-python-webapp (Apache-2.0, pinned commit)
• STACKIT Docs: Terraform provider
• STACKIT Docs: PostgreSQL Flex
• STACKIT Docs: Kubernetes Engine
• STACKIT Docs: RabbitMQ
• Google Cloud documentation: Cloud SQL introduction
• Google Cloud documentation: What is Cloud Run