The complete Alibaba Cloud to STACKIT migration guide

The migration in eight steps

1. 01

   1. Gather and pin the Terraform

   Collect every root module that uses the aliyun/alicloud provider and commit .terraform.lock.hcl. The run reports the provider as unpinned without a lock entry and caps the confidence of its units at MEDIUM, which is what you see in every unit of the example.

2. 02

   2. Assess

   Run stacktoit assess ./alibaba-terraform. It reads the files and connects to no Alibaba Cloud account. Resources that no module declares, such as objects created by hand, are not in the result, so add them to the Terraform first or list them by hand.

3. 03

   3. Read the output in this order

   assessment.json for class, target and reason of each unit. migration/technical-sequencing.md for the waves. migration/data-movement.md for the stateful units. execution/manual/actions.md for the manual steps and owners. index.html for the same in one workspace.

4. 04

   4. Resolve what the run leaves to you

   The example run lists five open requests. One blocks the draft: the STACKIT region (eu01 or eu02). Fill it in inputs-template.yaml and run again; the next run reads your answer. The other four (project, observability, public ingress, egress) are recorded but change nothing in this build, and the template says where each one is set instead.

5. 05

   5. Build the landing zone

   Create the STACKIT project layout, then the networks. A VPC has no one-to-one counterpart: its vSwitches become STACKIT networks and routing between them is planned with a Network Area where needed. Security groups follow, with a decision for every deny rule, because STACKIT rules only allow traffic.

6. 06

   6. Move the data

   Databases and buckets are stateful. The run lists them and sets the mechanism to UNKNOWN. You choose it, rehearse it and measure it.

7. 07

   7. Move compute and the edge

   General practice, not run output: rebuild or import the image of each server, then bring up the STACKIT load balancer, change DNS and switch the log collectors.

8. 08

   8. Cut over, observe, retire

   General practice, not run output: cut over in the order of the waves where it fits, keep the Alibaba Cloud side until the checks pass, and write down how each step is undone. The run leaves rollback to the person who carries out each step.

A web server, a database and a load balancer, assessed

A small Alibaba Cloud estate with nine resources, written for this page and assessed by StackToIT on 4 November 2026. Left: three blocks of the input. Right: the result the run recorded for four units, an excerpt of assessment.json with the values 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. The input blocks are shown in separate panes because they are not next to each other in main.tf.

resource "alicloud_instance" "web" {
  instance_name        = "shop-web-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       = "16.0"
  instance_type        = "pg.n2.2c.2m"
  instance_storage     = 100
  instance_name        = "shop-orders"
  vswitch_id           = alicloud_vswitch.app.id
  instance_charge_type = "Postpaid"
}

resource "alicloud_slb_load_balancer" "front" {
  load_balancer_name = "shop-front"
  load_balancer_spec = "slb.s2.small"
  address_type       = "internet"
}

[
  {
    "id": "alicloud_instance.web",
    "result": {
      "class": "RECONFIGURE",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT Compute Engine"
      },
      "reason": "An ECS instance becomes a STACKIT server. The instance type becomes a STACKIT flavor, the image is rebuilt or imported, and the attached disks and interfaces become volumes and network interfaces."
    }
  },
  {
    "id": "alicloud_db_instance.orders",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT PostgreSQL Flex"
      },
      "reason": "Managed PostgreSQL to managed PostgreSQL: data moves with pg_dump/pg_restore or logical replication, and the instance class becomes a Flex flavor."
    }
  },
  {
    "id": "alicloud_slb_load_balancer.front",
    "result": {
      "class": "RECONFIGURE",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT Network Load Balancer"
      },
      "reason": "A CLB or NLB load balancer becomes a STACKIT Network Load Balancer. Listeners and backends are rewritten, and the public address changes."
    }
  },
  {
    "id": "alicloud_security_group.app",
    "result": {
      "class": "RECONFIGURE",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT security groups"
      },
      "reason": "A security group becomes a STACKIT security group. STACKIT rules only allow traffic, so a deny rule or a priority order of the source needs a decision."
    }
  }
]

• Reasons you can hand over

  The ECS reason says the instance type becomes a STACKIT flavor, the image is rebuilt or imported, and disks and interfaces become volumes and network interfaces. The database reason says data moves with pg_dump and pg_restore or logical replication.

• A decision hides in a security group

  STACKIT rules only allow traffic, so a deny rule or a priority order of the source needs a decision from you.

• Drafted or not

  Run figures: 9 resources, 9 units, 0 generated as STACKIT Terraform, 9 left for the architect. For an Alibaba Cloud source the output holds terraform.tf, variables.tf and a README, and the rest is manual work.

The order the run computes

Waves follow references between resources: a unit moves after every unit it depends on. This is the migration plan the run wrote, not a schedule.

## Wave 1 — 5 unit(s)

| Unit | Class | Target |
|---|---|---|
| `alicloud_alidns_record.www` | RECONFIGURE / MEDIUM | STACKIT DNS |
| `alicloud_log_project.app` | RECONFIGURE / MEDIUM | STACKIT Logs |
| `alicloud_oss_bucket.media` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `alicloud_slb_load_balancer.front` | RECONFIGURE / MEDIUM | STACKIT Network Load Balancer |
| `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.web` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |

• Network first, data and compute last

  The VPC is in wave 1, the vSwitch and the security group in wave 2, and the database and the server in wave 3, because both reference the vSwitch.

• Edge units show up early

  The load balancer, the DNS record, the bucket and the log project reference nothing, so they land in wave 1. In your plan they move when the application is ready for them, not when the arithmetic says they can.

Every resource, its STACKIT target and class

Classes as the run decided them. The detail guides for databases, load balancers, functions, DNS, CDN and logs go deeper on their rows.

What differs on the way

Facts about STACKIT and about Alibaba Cloud DTS come from the pages listed under sources, read on the day this page was written.

• Names and addresses change

  OSS clients change to an S3 client, and the load balancer and elastic IP addresses change. DNS records and allow lists that name them change too.

• Databases clone, they do not restore in place

  STACKIT documents that PostgreSQL Flex has no in-place restore: you clone a backup into a new instance and point the clients at it. Alibaba Cloud DTS supports schema, full and incremental migration between ApsaraDB RDS instances (MySQL, MariaDB, SQL Server, PostgreSQL); the page names only RDS instances as destination, not STACKIT.

• Load balancer type

  The STACKIT Network Load Balancer is described as Layer 4. A classic balancer with HTTPS listeners may belong on the Application Load Balancer; the run maps it to the Network Load Balancer and leaves listeners to you.

• DNS features

  STACKIT DNS lists forward, reverse and secondary zones and states that DNSSEC zone signing is currently not available. Weighted and line-based resolution of the source needs a review.

• Logs are rewritten

  STACKIT Logs is built on Grafana Loki. Collection, queries and boards of Simple Log Service are rewritten.

Decisions your architects own

• Data mechanism and downtime

  For the database and the bucket: how, how fast, how long the business can stop. The run records RPO and downtime tolerance as NOT_PROVIDED until you fill them in the applications file.

• Security group semantics

  Deny rules and priority orders have no direct counterpart.

• Server images

  Rebuild from your own pipeline or import the Alibaba Cloud image. The run says only that one of the two happens.

• Balancer type per listener

  Network or Application Load Balancer.

• Wave plan and owners

  The waves are a starting point. Assign an owner and a date to every manual step; the run writes "timing to be scheduled by the owner".

Questions architects ask

Sources

• Alibaba Cloud docs: Migrate data between ApsaraDB RDS instances by using DTS
• STACKIT docs: PostgreSQL Flex, backup and clone
• STACKIT docs: Network Load Balancer, basic concepts
• STACKIT docs: DNS product overview
• STACKIT docs: Logs introduction