Comparing AWS, Azure, Google Cloud, Huawei, Alibaba and Oracle Cloud for a STACKIT migration

The same database, drafted from Azure

A small estate written for this page and assessed by StackToIT on 4 November 2026. Left: the PostgreSQL flexible server of the Azure input. Right: the STACKIT PostgreSQL Flex instance the engine wrote from it (the review comments above the block in the file are left out). The AWS and Google Cloud estates produce the same instance with their own source values.

resource "azurerm_postgresql_flexible_server" "orders" {
  name                   = "pg-orders"
  resource_group_name    = azurerm_resource_group.orders.name
  location               = azurerm_resource_group.orders.location
  version                = "16"
  administrator_login    = "orders"
  administrator_password = var.db_password
  sku_name               = "GP_Standard_D4s_v3"
  storage_mb             = 204800
  backup_retention_days  = 14
  zone                   = "1"

  high_availability {
    mode                      = "ZoneRedundant"
    standby_availability_zone = "2"
  }
}

resource "stackit_postgresflex_instance" "orders" {
  project_id = var.project_id
  name       = "pg-orders"
  version    = "16"
  flavor_id  = "4.32-replica"
  storage = {
    class = var.postgresflex_storage_class
    size  = 200
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.orders_allowed_cidrs
  }
  retention_days = 32
}

• Size comes from the source

  The source SKU has 4 vCPU and 16 GiB. The draft picks flavor 4.32-replica (4 vCPU, 32 GiB), the smallest high-availability PostgreSQL Flex flavor in the eu01 catalogue the run read, because the source runs a zone-redundant standby. STACKIT describes a replica set as three nodes that mirror each other; the run claims no zone placement or failover behaviour for them.

• Retention is transformed

  The source keeps backups for 14 days. The draft sets retention_days to 32 and marks the line TRANSFORMED in its ledger, so nobody reads it as an equal setting.

• Access and zones are yours

  The instance gets an access list from a variable without a default. The source zone and standby zone are not generated; the run records both as not carried.

Where a draft stops: Huawei Cloud and Oracle Cloud

From two of the runs. The Huawei Cloud, Alibaba Cloud and Oracle Cloud runs on this build write no STACKIT resource blocks, only an assessment, a plan and variables, so the evidence is the assessment record. Left: the Huawei RDS unit. Right: the Oracle Database system. Both records are shortened to id, class, confidence, target and reason; the Oracle record has no target at all.

{
  "id": "huaweicloud_rds_instance.orders",
  "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 flavor becomes a Flex flavor."
}

{
  "id": "oci_database_db_system.orders",
  "class": "REDESIGN",
  "confidence": "LOW",
  "reason": "STACKIT has no Oracle Database service. Decide whether the database changes engine, with a schema and procedure conversion, or stays on self-managed Oracle under your own licence."
}

• Same engine, a clear target

  Managed PostgreSQL on Huawei Cloud, Alibaba Cloud, AWS, Azure and Google Cloud is REPLATFORM with MEDIUM confidence and lands on PostgreSQL Flex. Data moves with pg_dump and pg_restore or with logical replication.

• No Oracle service on STACKIT

  The Oracle Database system is REDESIGN with LOW confidence and no target service. The record says to decide between a new engine with schema and procedure conversion, or Oracle self-managed under your own licence.

Six sources, one application

Each row is one run of the same application shape: a network and subnet, a virtual machine, a managed PostgreSQL database and an object bucket. The AWS estate has a second subnet for the database; the Huawei Cloud and Alibaba Cloud estates add the security group their database or server needs, which each run maps to STACKIT security groups.

Counts as the runs reported them. Every unit is MEDIUM confidence except the Oracle Database system, which is LOW. These are small estates; they show the shape of each source, not the effort of yours.

Service by service: where the sources differ

The Kubernetes rows come from separate runs of a cluster with its network, one per source cloud. The node pool rows show a coverage gap of this build, not a property of the clouds. In the EKS, AKS and GKE runs the node pool is assessed as a part of the cluster unit (its settings are listed under that unit in assessment.json), so it has no row of its own.

Options for sequencing a mixed estate

General practice for estates that come from more than one cloud. Each StackToIT run reads one root module, so a mixed estate is a set of runs.

How to decide

1. 01

   Start from the classes, not the cloud

   Read the class column of each run before you rank the sources. REDESIGN and MANUAL_REVIEW units, such as an Oracle Database or a node pool with no catalogue entry, set the schedule more than the number of resources.

2. 02

   Check what the run wrote

   Open terraform/ in each output. A folder with only terraform.tf, variables.tf and README.md means the plan exists but the resource blocks are the architect's to write.

3. 03

   Decide the project layout once

   The migration plan of every one of the six runs starts with the same open box: STACKIT organisation, folders and projects laid out, with one project per environment as the usual start. Answer it once for the whole estate and reuse the answer in each source run.

4. 04

   Keep one decision register for the estate

   decisions.json differs per run: 16 open decisions for AWS, 12 for Azure, 10 for Google Cloud, and none for Huawei Cloud, Alibaba Cloud and Oracle Cloud, whose units are all left to the architect. Merge the open decisions into one list before the first wave is planned, add your own for the three sources without drafts, and give each an owner.

5. 05

   Test the engine-specific points early

   The review lines of each database unit name what to test. In the AWS data estate behind our database architecture guide they were the extension list for PostgreSQL, SQL Agent jobs, linked servers and CLR assemblies for SQL Server, and authentication plugins for MySQL moving to MariaDB.

Questions architects ask

Sources

• STACKIT Object Storage overview
• STACKIT Kubernetes Engine overview
• STACKIT PostgreSQL Flex overview
• Architecture of STACKIT PostgreSQL Flex