Azure vs STACKIT: service mapping

What an assessed Azure estate maps to

A 13-resource estate was written for this page and assessed by StackToIT on 4 November 2026. The 13 resources form 9 units: the resource group, the queue, the blob container and the service plan are read as part of the units that use them. Seven units got a Terraform block, one needs no STACKIT resource and one is left to an architect.

Classes as the run decided them, all with MEDIUM confidence: the source provider version is not pinned by a lock file, and the run caps confidence at MEDIUM in that case. The target column names the resources the assessment proposes. The draft writes the instance, bucket or organization; users and credentials for PostgreSQL, Object Storage, Secrets Manager and RabbitMQ are created separately, while for Valkey the credential is part of the draft.

Services the run did not include

The public StackToIT documentation and the curated mapping list further pairs. They were not part of this demo estate, so the classes below are the usual ones, not a result for your estate.

A cache and a bucket, converted

From the same run. Left: the Azure input. Right: the resource blocks of the STACKIT Terraform the engine wrote; the review comments above each block in the file are left out here.

resource "azurerm_redis_cache" "sessions" {
  name                = "redis-shop-sessions"
  location            = azurerm_resource_group.shop.location
  resource_group_name = azurerm_resource_group.shop.name
  capacity            = 1
  family              = "C"
  sku_name            = "Standard"
  minimum_tls_version = "1.2"
}

resource "stackit_valkey_instance" "sessions" {
  project_id = var.project_id
  name       = "redis-shop-sessions"
  plan_name  = var.sessions_plan_name
  version    = var.sessions_version
  parameters = {
    sgw_acl = join(",", var.sessions_allowed_cidrs)
  }
}

resource "stackit_valkey_credential" "sessions" {
  project_id  = var.project_id
  instance_id = stackit_valkey_instance.sessions.instance_id
}

• The cache size is yours to pick

  family = C and capacity = 1 have no Valkey equivalent. The code takes the plan and the version as variables, and the clients get a new host and a generated credential.

• Cached data is usually rebuilt

  A session cache is normally warmed again on the target instead of copied, which is why the class is RECONFIGURE and not REPLATFORM.

Storage accounts become buckets

The blob container turns into one bucket named after the account and the container. The comment lines on the right are the engine's notes on the bucket in the order of the file; the provider-version warning and the trace line are left out.

resource "azurerm_storage_account" "media" {
  name                     = "stshopmediagwc"
  resource_group_name      = azurerm_resource_group.shop.name
  location                 = azurerm_resource_group.shop.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
  min_tls_version          = "TLS1_2"
}

resource "azurerm_storage_container" "images" {
  name                  = "images"
  storage_account_id    = azurerm_storage_account.media.id
  container_access_type = "private"
}

# NOT CARRIED (azurerm_storage_account.media): account_tier = Standard — stackit_objectstorage_bucket has name and object_lock only (pinned provider): the account's kind, performance tier and access tier are not generated.
# NOT CARRIED (azurerm_storage_account.media): account_replication_type = GRS — the replication is not generated: stackit_objectstorage_bucket has no replication setting (pinned provider) (STACKIT replicates within the region across three availability zones).
# WARNING storage-geo-replication: Geo-redundant replication to a paired region; STACKIT Object Storage has no managed cross-region replication, so a second copy needs its own sync job.
# REPLICATION: the source replicates to another region; STACKIT Object Storage does not replicate across regions — sync to a bucket in the second region (rclone) if the copy is required.
# LEDGER geo-replication: second region → none — sync to a second bucket if required — UNSUPPORTED
resource "stackit_objectstorage_bucket" "media" {
  project_id = var.project_id
  name       = "stshopmediagwc-images"
}

• A different API, not just a new endpoint

  Azure Blob is not S3-compatible, so applications switch from the Azure Storage SDK to an S3 SDK and from account keys or SAS tokens to S3 access keys. The STACKIT Object Storage documentation describes an S3-compatible API over HTTPS.

• Geo-replication is not carried

  The account used GRS. The bucket block has no replication setting, so a second copy in another region is a job you set up yourself, for example with rclone.

Settings that bite in practice

These come from the not-carried notes and the reasons of the run, next to the unit they belong to.

• Resource groups

  STACKIT has no resource groups. The draft places every resource in one project (the project_id variable), and a person decides how the groups map to projects and roles.

• Private databases

  public_network_access_enabled = false has no counterpart. Clients reach the PostgreSQL Flex instance through its ACL, so you list their CIDRs in a variable that has no default.

• Key Vault settings

  Purge protection, soft-delete retention, tenant and access policies are not generated. Secrets are recreated one by one in the Secrets Manager instance.

• App Service settings

  The Cloud Foundry organization is a container only. Runtime version, plan and settings move into a manifest and service bindings.

• Service Bus settings

  The namespace tier is not carried, and neither is max_delivery_count = 10 of the orders queue. Queues and topics are configured as queues and exchanges in the RabbitMQ instance.

• Cosmos DB

  Consistency levels, partition keys and the change feed are rethought, and the run writes no Terraform for the account.

The one unit left for an architect

The Cosmos DB account for the NoSQL API is the only unit of the estate without a draft. The assessment records the class, the candidate targets and the reason.

resource "azurerm_cosmosdb_account" "catalog" {
  name                = "cosmos-shop-catalog"
  location            = azurerm_resource_group.shop.location
  resource_group_name = azurerm_resource_group.shop.name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = "germanywestcentral"
    failover_priority = 0
  }
}

{
  "id": "azurerm_cosmosdb_account.catalog",
  "result": {
    "class": "REDESIGN",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT MongoDB Flex or PostgreSQL Flex (JSONB) — data-model redesign",
      "resources": [
        "stackit_mongodbflex_instance"
      ]
    },
    "reason": "The NoSQL (Core/SQL) API is Cosmos DB's own protocol and query dialect; nothing else speaks it. The access layer is rewritten for MongoDB Flex or PostgreSQL JSONB, and partition-key design, consistency levels and change feed are re-thought."
  }
}

How to use the map on your own estate

1. 01

   Assess the Terraform

   Run the assessment on the AzureRM or AzAPI root module. The engine reads files and connects to no Azure account.

2. 02

   Read the class before the target

   REPLATFORM and RECONFIGURE mean the work is bounded. REDESIGN and MANUAL_REVIEW mean an architect owns a decision first.

3. 03

   Open the not-carried notes

   Each block lists what it does not carry. Those lines are your work list for settings, access and sizing.

4. 04

   Check data movement separately

   The run lists the stateful units and leaves the method open. Size, change rate and tolerated downtime decide it, and the source states none of them.

Questions about the mapping

Sources

• STACKIT documentation: Object Storage
• STACKIT documentation: PostgreSQL Flex
• STACKIT documentation: RabbitMQ
• STACKIT documentation: Secrets Manager
• STACKIT documentation: MongoDB Flex