ALIBABA CLOUD → STACKIT · CHECKLIST

Alibaba Cloud to STACKIT migration checklist

Tick these in order: discovery, design, build, data, cutover, after. Every check names the file of a StackToIT assessment where the answer is written, so the checklist is a way to read the output as much as a list of tasks. The files named here come from a 13-resource Alibaba Cloud estate assessed on 4 November 2026.

1. Discovery: know what you run

Goal: every Alibaba Cloud resource in Terraform has a class, a target and a reason. Command: stacktoit assess on the folder of your Terraform roots. The run reads files and connects to no account.

  • Every Terraform root is in the scan

    Roots that use the aliyun/alicloud provider. Resources created in the console are not in Terraform, so list them separately.

  • Variables have values

    A sensitive variable with no value leaves a secret unassessed. Pass a variable file with --var-file. File: the Source line of the console summary and source_inputs in assessment.json.

  • The provider version is pinned by a lock file

    Without a lock entry the run records a root issue (source-provider-unpinned) and caps confidence at MEDIUM for every unit. File: summary.root_issues in assessment.json.

  • Unknown resource types are listed

    A type StackToIT does not catalogue comes back as MANUAL_REVIEW with nothing assessed, and units linked to it are capped at LOW. File: summary.unknown_types in assessment.json, present when there is one.

  • Counts add up

    Resources, units and classes in the summary match what you expect. File: summary in assessment.json.

2. Design: decide what the run cannot

Goal: every REDESIGN and MANUAL_REVIEW unit has an owner and a decision, and the blocking requests are answered.

  • Every MANUAL_REVIEW, REDESIGN and BLOCKED unit is reviewed

    File: engineering/architect-report.md. PolarDB, RAM users and roles, and unknown types live here.

  • Blocking requests are answered

    In the example run there are two: the target region and the sensitive db_password variable. Answer the region in inputs-template.yaml and rerun with --inputs; supply the variable through a tfvars file or TF_VAR_db_password in a private run, never in the template.

  • The STACKIT organisation and projects exist

    One project per environment is the usual start. File: migration/landing-zone-requirements.md, sections 1 and 2.

  • The target services are known

    The run lists the STACKIT service families your units map to, with counts. It also says the draft itself needs none enabled, because it writes no resource block, so enabling them is part of your build. File: migration/landing-zone-requirements.md, section 8.

  • Reviews are recorded with a role

    Record each decision in decisions.yaml with a role and a rationale. File: review/decisions.yaml.

The checks the run writes itself

Left: the Before wave 1 list from migration/technical-sequencing.md, verbatim. Right: the stub for the blocking region request from inputs-template.yaml.

StackToIT outputmigration/technical-sequencing.md
## Before wave 1

- [ ] Architect has reviewed every MANUAL_REVIEW, REDESIGN and BLOCKED unit in engineering/architect-report.md.
- [ ] STACKIT organisation, folders and projects are laid out (one project per environment is the usual start).
- [ ] Data-transfer method and cutover window agreed per data unit (databases, buckets, caches).
StackToIT outputinputs-template.yaml
  # target.region (TARGET_SELECTION, request state OPEN)
  # needed: The STACKIT region the migrated estate is built in.
  - id: INP-TSE-1eaf5b60fa62
    kind: TARGET_SELECTION
    topic: target.region
    scope:
      profile: default
    # options: eu01 | eu02
    value: ""                # pick one of the options above
  • Three checks before any wave

    Architect review of manual units, a laid-out STACKIT organisation, and an agreed data-transfer method and cutover window per data unit.

  • A choice of two regions

    The options in the stub are eu01 and eu02. The services list is derived from eu01 until you answer.

3. Build: work in the order of the waves

Goal: networks and keys first, workloads last, with an owner for every work package.

  • Owners are named for every work package

    A package with Owner assignment required has no role in the owner table. File: execution/README.md, Work packages.

  • Waves are respected

    A unit moves after the units it depends on. File: migration/technical-sequencing.md. This is a technical order, not a schedule.

  • The draft is treated as a skeleton

    For an Alibaba Cloud source the draft holds only terraform.tf, variables.tf and a README. File: terraform/. It pins the STACKIT provider and needs OpenTofu or Terraform 1.11 or later.

  • Each manual step has a done condition and a rollback

    The plan states when a step is done and leaves the rollback to the person. File: execution/manual/actions.md.

  • Progress is recorded

    Mark each step BLOCKED, IN_PROGRESS, DONE, FAILED or WAIVED in the journal. File: review/progress.yaml, read again with --progress.

4. Data: choose a mechanism per stateful unit

Goal: every database, cache and bucket has a transfer method, a window and a check.

  • Each stateful unit has a mechanism

    The run lists them with the mechanism UNKNOWN until you choose. File: migration/data-movement.md. A system installed on a server's disk is not read as stateful and is not listed.

  • Data class, RPO and downtime are given

    They come from your applications file, word for word. Without it they stay NOT_PROVIDED.

  • PostgreSQL has a method

    The run names pg_dump with pg_restore or logical replication for a PostgreSQL instance. Check extensions against STACKIT's supported list.

  • Redis has a copy and a check

    STACKIT documents MIGRATE with a check that compares INFO KEYSPACE and a diff of sorted key lists.

  • Object copies are verified

    Compare object counts and sizes on both sides, for example with a sync tool of your choice. This is practice, not an output of the run.

What the data list looks like

Verbatim from migration/data-movement.md of the same run.

StackToIT outputmigration/data-movement.md
| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| alicloud_db_instance.main | alicloud_db_instance | STACKIT PostgreSQL Flex |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| alicloud_kvstore_instance.sessions | alicloud_kvstore_instance | STACKIT Key Value Store (Valkey) |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| alicloud_oss_bucket.uploads | alicloud_oss_bucket | STACKIT Object Storage |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
  • Three units

    A database, a cache and a bucket, each with the mechanism UNKNOWN and the state DECISION_REQUIRED.

  • What is not here

    Size, change rate and transfer time are never stated by the run. They are yours to measure.

5. Cutover: switch and keep a way back

Goal: a rehearsed switch with a stated rollback.

  • Public addresses and DNS are listed

    The run notes that a load balancer public address changes. Cutover facts are in migration/technical-sequencing.md; an empty section does not mean nothing has to be cut over.

  • Security rules are re-read

    STACKIT security group rules only allow traffic. A deny rule or a rule priority of the source needs a decision.

  • Secrets are re-read by the applications

    Applications change how they read secrets. Alibaba Cloud KMS marks the current version with labels such as ACSCurrent; check how your code reads them.

  • Identities are replaced

    RAM roles are replaced by service accounts with roles in a project. STACKIT service accounts have no access until you assign roles.

  • A rollback is written down per step

    The plan leaves the rollback of each manual step to the person. Write it before the window.

6. After: close and record

Goal: the Alibaba Cloud side is retired on purpose, and the plan matches reality.

  • The source stays until the agreed period has passed

    Keep it untouched or read-only. STACKIT's Redis tutorial says the source backup must be kept until the consistency of the target is confirmed.

  • RAM users and AccessKeys are removed last

    Alibaba Cloud RAM users hold console passwords or AccessKeys. Remove them once no application reads from Alibaba Cloud.

  • The assessment is rerun with the answers

    Rerun with --inputs, --decisions, --applications and --progress so the plan reflects what you decided.

  • Source resources are deleted

    Delete the resources you replaced and check that nothing keeps billing.

Checklist questions

Does the checklist replace the assessment?

No. It tells you which file of the assessment answers which check. Run the assessment first.

Do I need an Alibaba Cloud account to run it?

No. StackToIT reads Terraform and OpenTofu files and does not connect to an Alibaba Cloud account.

Which checks does StackToIT tick for me?

None. It writes the lists and states what is open. Marking steps done is yours, in the progress journal.

Where do I start with a large estate?

Start with discovery on the whole estate, then design the REDESIGN and MANUAL_REVIEW units, and only then fix the wave plan.

Sources

Your next move: STACKIT.

Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.