Alibaba Cloud Terraform to STACKIT: the workflow, step by step

Step 1: the input, a root module you already have

A small estate written for this page: a VPC with one vSwitch and a security group, an ECS instance, a PostgreSQL database and an OSS bucket. StackToIT reads Terraform and OpenTofu root modules that use the aliyun/alicloud provider; it does not connect to your Alibaba Cloud account.

resource "alicloud_instance" "app" {
  instance_name        = "${var.app_name}-app-01"
  instance_type        = "ecs.g7.large"
  image_id             = "ubuntu_22_04_x64_20G_alibase_20240926.vhd"
  vswitch_id           = alicloud_vswitch.app.id
  security_groups      = [alicloud_security_group.app.id]
  system_disk_category = "cloud_essd"
  system_disk_size     = 40
}

resource "alicloud_db_instance" "orders" {
  engine               = "PostgreSQL"
  engine_version       = "15.0"
  instance_type        = "pg.n2.2c.1m"
  instance_storage     = 100
  instance_charge_type = "Postpaid"
  vswitch_id           = alicloud_vswitch.app.id
  instance_name        = "${var.app_name}-db"
}

resource "alicloud_oss_bucket" "uploads" {
  bucket = "${var.app_name}-uploads"
  acl    = "private"
}

• Variables are read

  The names in the example come from var.app_name. Variable files that sit beside the module are read with it; pass others with --var-file.

• Pin the provider

  The run warns when no lock file pins the alicloud provider and, for that reason, caps every unit at MEDIUM confidence. Commit .terraform.lock.hcl first. The demo pins aliyun/alicloud 2.1.0, a version published in the Terraform Registry; its attribute names match that version's registry documentation, but OpenTofu did not validate the files.

Step 2: one command

The documented form is stacktoit assess SOURCE OUTPUT. The pane shows the command as it was run, from inside the demo's input folder. It used --offline, so no network request was made, and --no-validate skipped OpenTofu validation of the source because the demo had no provider mirror. Excerpt of the console output, taken as written.

# run from inside the demo's input folder; the output folder sits next to it
stacktoit assess . ../out --offline --no-validate

StackToIT Assess
────────────────────────────────────────────
Source:                 input
Source files:           1
Resources scanned:      6
Migration units:        6  (6 instances)
Unit dependencies:      5
Source checks:          Built-in source checks passed — OpenTofu validation of the source was not run

STACKIT mapping
────────────────────────────────────────────
DIRECT              0  
RECONFIGURE         5  █████████████████████████ 83%
REPLATFORM          1  █████ 16%
CONTAINERIZE        0  
REDESIGN            0  
MANUAL_REVIEW       0  
BLOCKED             0    (the mapping class BLOCKED, not the execution blockers, which Migration readiness counts)

Confidence  HIGH 0 · MEDIUM 6 · LOW 0

• Six resources, six units

  Each resource in this estate is a unit of its own. Five are RECONFIGURE and one, the database, is REPLATFORM. Confidence is MEDIUM for all six.

• No STACKIT Terraform for this source

  On this build the run writes no STACKIT resource blocks for Alibaba Cloud sources. The terraform folder holds the provider setup and the list of units left for your architects.

• Run without --no-validate when you can

  Without that flag the run also attempts OpenTofu validation of your source, which needs the provider to be available.

Step 3: the files and the question each answers

The run writes a folder of reviewable files. These are the ones you open first.

index.html

The overview: open it in a browser, offline, for a unit-by-unit view.

assessment.json

Per unit: class, confidence, target, reason and the settings it named.

engineering/architect-report.md

The reasoning per unit, the review queue and what is left to you.

migration/technical-sequencing.md

The order of the units by dependency, in waves.

migration/data-movement.md

Which units hold data and what must be decided before it moves.

migration/work-packages.csv

The work, grouped by owner role.

execution/manual/actions.md

The manual steps, each with who, when, risk and the condition that marks it done.

inputs-template.yaml

The questions the run asks you; answering one and running again changes the draft.

decisions-template.yaml

Where an architect records a review.

terraform/

The provider setup and variables of the STACKIT draft, and the list of units left for the architect.

Step 4: read one unit end to end

The database, as the run assessed it. Excerpt of assessment.json with the values exactly as the run wrote them. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

{
  "id": "alicloud_db_instance.orders",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT PostgreSQL Flex",
      "resources": [
        "stackit_postgresflex_instance",
        "stackit_postgresflex_database",
        "stackit_postgresflex_user"
      ]
    },
    "reason": "Managed PostgreSQL to managed PostgreSQL: data moves with pg_dump/pg_restore or logical replication, and the instance class becomes a Flex flavor."
  }
}

• Same engine, new service

  PostgreSQL to PostgreSQL Flex is REPLATFORM: the run names pg_dump with pg_restore or logical replication as the ways the data moves, and turns the instance class into a Flex flavor.

• Seven settings named

  engine, engine_version, instance_charge_type, instance_name, instance_storage and two more are listed for your database team.

• Trace it

  stacktoit explain ./migration alicloud_db_instance.orders prints the chain of evidence behind the classification.

Step 5: the order the units move

Excerpt of migration/technical-sequencing.md, taken as written. A unit moves after every unit it depends on; units in one wave can move in parallel.

## Wave 1 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `alicloud_oss_bucket.uploads` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `alicloud_vpc.main` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 2 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `alicloud_security_group.app` | RECONFIGURE / MEDIUM | STACKIT security groups |
| `alicloud_vswitch.app` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 3 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `alicloud_db_instance.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |
| `alicloud_instance.app` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |

• A starting point, not a schedule

  The waves come from dependencies only. Your calendar, change windows and data copies shape the real schedule.

Step 6: who gets the work

From migration/work-packages.csv. The run groups the manual work by area and names an owner role for each.

All five packages are free of decisions and a person can start each now. No step is carried out by OpenTofu or a script on this build.

Step 7: what to change before you apply anything

The run is a proposal. These are the things it asks of you, in the order that works.

1. 01

   Pin the source provider

   Commit .terraform.lock.hcl for the alicloud provider and run again. The run names the missing lock entry as the cause of the warning and of the MEDIUM cap; a run with a lock file was not made for this page, so check the new confidence values rather than assume them.

2. 02

   Answer the blocking request

   inputs-template.yaml holds one request that blocks the draft: target.region, with eu01 and eu02 as options. Copy the file, fill the value and pass it with --inputs. The draft variables show region with a default of eu01; the answer is your choice.

3. 03

   Set the project

   The STACKIT project is a variable of the draft (project_id), which the template says to set in terraform.tfvars or TF_VAR_project_id.

4. 04

   Review the units

   Read engineering/architect-report.md from the review queue down, and record your reviews in the decisions file. A review records a decision; it does not change the draft.

5. 05

   Choose the data mechanisms

   data-movement.md lists the database and the bucket with the mechanism UNKNOWN. Decide each from size, change rate and tolerated downtime.

6. 06

   Run again and verify

   After answers and reviews, run assess again into a new output folder, check it with stacktoit verify ../out-new and compare it with the first run using --same-as ../out. Keep both folders as a record of what changed.

Questions about the workflow

Sources

• STACKIT Docs: Object Storage limits
• Alibaba Cloud: data migration solutions for OSS
• STACKIT Docs: PostgreSQL Flex flavors and performance classes
• STACKIT Docs: use custom images with the IaaS API
• Terraform Registry: aliyun/alicloud provider 2.1.0