Huawei Cloud to STACKIT migration checklist

The demo estate in one view

Seven Terraform resources became seven units: six RECONFIGURE and one REPLATFORM, all with MEDIUM confidence. The classes tell you how much work to expect, not whether to proceed.

For a Huawei Cloud source this build writes no STACKIT resource blocks; all seven units are manual steps in six work packages.

1. Discovery

Know exactly what the assessment saw, and what it cannot see.

• Every root module is in the folder

  Count the modules you run against the line “modules not seen” in assurance/source-compatibility.md. It must read 0, and the resource count must match your own inventory.

• The provider version is pinned

  Commit .terraform.lock.hcl. The same file reports the huaweicloud provider as UNPINNED and states that until it is pinned the units are capped at MEDIUM confidence.

• Variable values are available

  Put the variable file beside the code. A sensitive variable without a value leaves its unit marked as missing an input and the source completeness as partial in engineering/architect-report.md.

• Console-made resources are listed

  Terraform shows only what Terraform manages. Compare the unit list in assessment.json with the account, and add what the code does not describe.

• Disk contents are accounted for

  migration/data-movement.md says data on the disks of a server is not looked at. Name who inventories databases and files installed on the ECS instance.

2. Design

Decide before you build. These checks turn the open questions of the run into answers.

• Region answered

  Copy the target.region request from inputs-template.yaml into your inputs file, choose eu01 or eu02 and pass the file with --inputs. It is the one request that blocks the draft, and migration/landing-zone-requirements.md asks you to check its services against the chosen region.

• Review queue read top to bottom

  Open the Architect review queue in engineering/architect-report.md. In the demo the PostgreSQL unit leads it. Anything REDESIGN or MANUAL_REVIEW in your own run comes first.

• Address ranges chosen

  The landing-zone file section Address ranges says the draft states no prefix. Pick the STACKIT network ranges yourself and check them against everything you connect.

• Security group rules reviewed

  The run notes that STACKIT rules only allow traffic, so a deny rule or a priority order in the source needs a decision. Look for both in the source rules.

• Resilience requirement written down

  assurance/resilience.md states that no RTO or RPO was provided and calls no unit resilient. Write the requirement into the applications file and re-run.

• Owners named

  migration/work-packages.csv lists a role per package in its owner column. Replace roles with people. Where a run cannot place a role, the owner column of execution/README.md reads Owner assignment required; in this demo every package has a role, so the check is for your own estate.

3. Build

The sequence the run computes is dependency order, not a schedule.

• Landing zone exists

  Create the STACKIT organization and project that migration/landing-zone-requirements.md describes. The draft’s variable var.region defaults to eu01 until you answer.

• Network before everything

  Wave 1 holds the VPC, security group, bucket and DNS record; wave 2 the subnet; wave 3 the server and the database. Follow that order in migration/technical-sequencing.md.

• Each manual step has an owner and a done-condition

  Every step in execution/manual/actions.md states who carries it out and when it is done. Tick them there and in the progress journal progress-template.yaml, copied to review/progress.yaml.

• Server image planned

  The run says the image is rebuilt or imported and the flavor becomes a STACKIT flavor. Decide which, and how disks and interfaces map to volumes and network interfaces.

• Database flavor chosen

  The managed PostgreSQL flavor becomes a Flex flavor. Check the major version against STACKIT’s release notes: version 14 reaches end of support on 12 November 2026, and version 15 or higher is the target.

4. Data

StackToIT never moves data. These checks make sure someone decides how.

• A mechanism per stateful unit

  migration/data-movement.md lists the bucket and the database with mechanism UNKNOWN and state DECISION_REQUIRED. Choose a mechanism for each and record it.

• Downtime and recovery point stated

  Data class, RPO and downtime tolerance read NOT_PROVIDED until the applications file gives them. Provide them before choosing between a dump and a replication tool.

• Database moved with a tested method

  The run names pg_dump with pg_restore or logical replication for the PostgreSQL move. Rehearse on a copy, and time it.

• Bucket clients re-pointed

  An OBS bucket becomes an S3-style bucket. Clients change endpoint and credentials, and lifecycle, replication and access settings need review. A tool such as rclone can do the copy, as general practice.

• Counts and checksums compared

  After each copy compare object counts, row counts and a sample of checksums, and keep the output as the evidence for the sign-off.

The commands, and the order the run proposes

Run the assessment from the folder that holds the Terraform, then verify the published package. The left pane is the command syntax from the StackToIT CLI documentation (assess and verify), with an example output folder; it is not a run file. The right pane is the sequence from the demo run, taken from migration/technical-sequencing.md.

stacktoit assess . ../out --offline
stacktoit verify ../out

## Wave 1 — 4 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_dns_recordset.app` | RECONFIGURE / MEDIUM | STACKIT DNS |
| `huaweicloud_networking_secgroup.app` | RECONFIGURE / MEDIUM | STACKIT security groups |
| `huaweicloud_obs_bucket.invoices` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `huaweicloud_vpc.main` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 2 — 1 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_vpc_subnet.data` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 3 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_compute_instance.app` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `huaweicloud_rds_instance.db` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |

5. Cutover

• New addresses known

  The cutover section of migration/technical-sequencing.md finds no DNS value the draft re-binds, so what the record points to at cutover is your input. Write it down before the window.

• DNS lines and TTL reviewed

  The run flags line-based resolution of the source record for review. Lower the TTL in advance and keep the old value for rollback.

• Rollback written for every step

  execution/manual/actions.md says the plan does not know how a manual step is undone: the person carrying it out records how. Do that before the window.

• Freeze and window agreed

  Agree the freeze on writes and the window with the application owners. The run gives no time estimate and neither does this list.

6. After

• The package is unchanged

  Run stacktoit verify on the output folder. It checks file integrity and agreement between artifacts; it does not prove anything happened in a cloud.

• Acceptance checks exist

  execution/verify/checks.md states that the plan names no check before or after a step. Write your own: functional tests, a restore test and a login test.

• Huawei Cloud retired on purpose

  The decommission wave of the migration plan is empty. Schedule the shutdown, keep the last backups for a defined period, then delete.

• Re-run after every change

  Whenever the source, the inputs or the applications file changes, run the assessment again and compare the new output with the previous one: stacktoit verify with the --same-as flag reports whether the inputs differ and where comparable files conflict.

Questions about the checklist

Sources

• STACKIT PostgreSQL Flex: Release notes
• StackToIT docs: verify
• StackToIT docs: Design inputs and decisions
• StackToIT docs: Application mapping
• StackToIT docs: assess