ApsaraDB RDS to STACKIT managed databases

The migration in six steps

1. 01

   1. Inventory by engine

   Run stacktoit assess on the Terraform. The engine value of each alicloud_db_instance picks the target, so list the instances by engine before you plan anything else. engineering/architect-report.md names seven settings per instance, among them engine, engine_version, instance_type and instance_storage, as critical settings left to you.

2. 02

   2. Take the target the run names

   In the example run below, the PostgreSQL instance maps to STACKIT PostgreSQL Flex, the MySQL instance to STACKIT MariaDB and the SQL Server instance to STACKIT SQLServer Flex. Each carries a reason you can hand to the database owner.

3. 03

   3. Settle network placement first

   The databases sit in wave 3 because they depend on the vSwitch, which depends on the VPC. The run places VPC in wave 1, vSwitch in wave 2 and the databases in wave 3, so the STACKIT networks come before any data lands.

4. 04

   4. Choose the data-movement mechanism

   The run lists five stateful units and sets the mechanism of each to UNKNOWN with the state DECISION_REQUIRED. Size, change rate, tolerated downtime and recovery point are not in Terraform, so you provide them in the applications file and pick the mechanism.

5. 05

   5. Rehearse the restore on STACKIT (practice)

   General practice, not run output: restore a copy into a new STACKIT instance, run the application tests against it and measure the duration. The rehearsal gives you the downtime figure that the Terraform cannot contain.

6. 06

   6. Cut over and keep the way back

   Point the application at the STACKIT endpoint. As a matter of practice, keep the Alibaba Cloud instance read-only until the checks pass, and record how the step is undone. The execution package leaves rollback to the person who carries out each manual step.

Three RDS instances, assessed

A small Alibaba Cloud estate written for this page and assessed by StackToIT on 4 November 2026. Left: the three database blocks of the input. Right: the result the run recorded for them, 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.

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_db_instance" "catalog" {
  engine               = "MySQL"
  engine_version       = "8.0"
  instance_type        = "mysql.n2.medium.2c"
  instance_storage     = 50
  instance_name        = "shop-catalog"
  vswitch_id           = alicloud_vswitch.app.id
  instance_charge_type = "Postpaid"
}

resource "alicloud_db_instance" "billing" {
  engine               = "SQLServer"
  engine_version       = "2019_std_ha"
  instance_type        = "mssql.x4.large.s2"
  instance_storage     = 200
  instance_name        = "shop-billing"
  vswitch_id           = alicloud_vswitch.app.id
  instance_charge_type = "Postpaid"
}

[
  {
    "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_db_instance.catalog",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT MariaDB"
      },
      "reason": "STACKIT offers MariaDB, not MySQL; test MySQL-specific features before cut-over, and move the data with a logical dump."
    }
  },
  {
    "id": "alicloud_db_instance.billing",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT SQLServer Flex"
      },
      "reason": "Managed SQL Server to SQLServer Flex: check the edition and features in use, and move the data with a backup and restore."
    }
  }
]

• The engine decides

  The same resource type produced three different targets. PostgreSQL stays PostgreSQL, SQL Server stays SQL Server, and MySQL becomes MariaDB.

• The reasons travel with the target

  PostgreSQL: the data moves with pg_dump and pg_restore or logical replication, and the instance class becomes a Flex flavor. SQL Server: check edition and features, and move the data with a backup and restore. MySQL: test MySQL-specific features before cut-over and move the data with a logical dump.

• No Terraform for these databases

  For an Alibaba Cloud source this build writes no STACKIT database resource. The run marks all seven units as left for your architects, so the STACKIT instances are set up by hand or in your own Terraform.

How the database estate maps

Classes as the run decided them. PolarDB separates compute from shared storage, which has no STACKIT counterpart, so the run gives it confidence LOW and leaves the target to you. The Redis reason adds: confirm that no Tair-specific commands are in use.

What the STACKIT documentation says about each target

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

• PostgreSQL Flex: clone, not restore

  Backups run daily and include transaction logs, and point-in-time restore works for all backups. A clone restores a chosen backup to a new instance in the same project. STACKIT offers no in-place restore, so clients are pointed to the clone.

• SQLServer Flex: a restore does not overwrite

  A backup is taken once a day and on demand. A restore cannot overwrite a database: the existing one has to be deleted beforehand. Point-in-time restore uses an RFC3339 timestamp.

• MariaDB: plan shape matters

  Replica plans have three nodes and high availability across availability zones. Single-node plans have no high availability and are not recommended for production. Moving to a higher plan causes downtime.

• Alibaba side: DTS stays between RDS instances

  DTS offers schema, full and incremental migration between ApsaraDB RDS instances (MySQL, MariaDB, SQL Server, PostgreSQL). The page we read names only RDS instances as destination, not a STACKIT database, so confirm another route before you design around DTS.

Decisions your architects own

• MySQL to MariaDB

  Which MySQL features do the applications use? The run asks you to test them before cut-over. Decide whether MariaDB is acceptable or whether the workload needs another route.

• Plan and availability

  Single-node or replica plan, and which performance class. The instance_type of the source becomes a flavor, and the mapping is not one to one.

• Mechanism per database

  Dump and restore, logical replication, backup and restore, or a replication tool you operate. Choose from data size, change rate and the downtime the business accepts.

• PolarDB target

  PostgreSQL Flex or MariaDB, by the compatible engine, after a test of the workload there. The demo cluster sets db_type MySQL, so on our reading MariaDB is the candidate to test first.

• Recovery point and ownership

  Fill data class, RPO and downtime tolerance in the applications file. Until you do, the run records them as NOT_PROVIDED and assumes nothing.

Questions database teams ask

Sources

• STACKIT docs: PostgreSQL Flex, backup and clone
• STACKIT docs: Backup and restore in SQLServer Flex
• STACKIT docs: Service plans of MariaDB
• Alibaba Cloud docs: Migrate data between ApsaraDB RDS instances by using DTS