Alibaba OSS to STACKIT Object Storage, step by step

Step 1: one bucket with real settings, assessed

A small Alibaba Cloud estate written for this page: three buckets, assessed by StackToIT on 4 November 2026. Left: the bucket with the most settings, taken from the input. Right: the result the run recorded for it, an excerpt of assessment.json with the values exactly 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_oss_bucket" "assets" {
  bucket        = "shop-assets-prod"
  storage_class = "Standard"
  acl           = "private"

  versioning {
    status = "Enabled"
  }

  server_side_encryption_rule {
    sse_algorithm = "AES256"
  }

  lifecycle_rule {
    id      = "expire-tmp"
    prefix  = "tmp/"
    enabled = true
    expiration {
      days = 30
    }
  }

  cors_rule {
    allowed_origins = ["https://shop.example.com"]
    allowed_methods = ["GET", "HEAD"]
    allowed_headers = ["*"]
    max_age_seconds = 3600
  }
}

{
  "id": "alicloud_oss_bucket.assets",
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT Object Storage",
      "resources": [
        "stackit_objectstorage_bucket",
        "stackit_objectstorage_credentials_group",
        "stackit_objectstorage_credential"
      ]
    },
    "reason": "An OSS bucket becomes a STACKIT Object Storage bucket with an S3 API. Applications that use the OSS SDK change their client; lifecycle, replication and access settings need review."
  }
}

• Class: RECONFIGURE

  The bucket keeps its role and gets a new shape. All three buckets of the run are RECONFIGURE with MEDIUM confidence, in wave 1, with no dependency on any other unit.

• Three target resources

  The run names stackit_objectstorage_bucket, stackit_objectstorage_credentials_group and stackit_objectstorage_credential. The bucket needs credentials for the clients that use it, so they are part of the target.

• The client changes

  Applications that use the OSS SDK change their client to an S3 client. That is the run’s reason in its own words, and it is the part of the move that touches application code.

Step 2: the settings the run names for you

StackToIT lists every setting it read from the bucket and does not carry any of them silently. For the bucket above it names 13 settings; the other two buckets name 3 and 4.

• assets: 13 settings

  acl, bucket, storage_class, versioning.status, server_side_encryption_rule.sse_algorithm, lifecycle_rule.id, lifecycle_rule.prefix, lifecycle_rule.enabled, lifecycle_rule.expiration.days, cors_rule.allowed_origins, cors_rule.allowed_methods, cors_rule.allowed_headers and cors_rule.max_age_seconds.

• archive: 3 settings

  acl, bucket and storage_class. The Archive storage class is the one to look at: the STACKIT Object Storage introduction names no storage classes, so plan this bucket as ordinary storage and decide how its access pattern is served.

• site: 4 settings

  acl, bucket, website.index_document and website.error_document. The bucket is public-read and serves a static site.

• None is drafted

  On this build the run writes no STACKIT resource block for Alibaba Cloud sources. The draft folder lists the three buckets as left for the architect, so the bucket, credentials and policies are created by your team from the named settings.

Step 3: what STACKIT documents for each setting

The right-hand column is taken from the STACKIT Docs pages listed under the sources, not from the run. Check them against the region and project you land in.

Bucket names must be unique across the whole system, 3 to 63 characters. A name such as shop-assets-prod may already be taken, so check the name before you plan clients around it.

Step 4: the data copy is listed, not chosen

StackToIT never moves data. For the three buckets it writes a data-movement file that lists each one as a stateful unit and leaves the mechanism open. Excerpt of migration/data-movement.md, taken as written.

StackToIT never moves data. 3 stateful source units are listed here: a person must choose a data-movement mechanism for each, and none is chosen (the mechanism is UNKNOWN).

State: DECISION REQUIRED.

## Stateful source units

| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| alicloud_oss_bucket.archive | alicloud_oss_bucket | STACKIT Object Storage |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| alicloud_oss_bucket.assets | alicloud_oss_bucket | STACKIT Object Storage |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| alicloud_oss_bucket.site | alicloud_oss_bucket | STACKIT Object Storage |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |

• Mechanism UNKNOWN

  The size of the data, its change rate and the downtime you tolerate are not in the Terraform, so the run cannot pick a method. It asks a person to.

• Data class, RPO, downtime

  The three columns show NOT_PROVIDED. They are filled from an applications file you pass to the run, word for word; nothing is assumed.

Step 5: moving the objects

General practice for the copy itself. The run does not run any of it.

1. 01

   Create the target first

   Create the Object Storage bucket and a credentials group, then credentials for the copy job. Create the lifecycle, CORS and encryption settings from Step 3 before the first object lands.

2. 02

   Pick a tool that speaks to both ends

   The OSS documentation covers copies from OSS to OSS: ossutil cp for small and medium volumes in one region and account, same-region replication for large or cross-account moves and cross-region replication across regions. The ossutil cp page states that cp does not copy across accounts or regions. For a copy from OSS to an S3 API, use a tool that has a remote for each side, for example rclone.

3. 03

   Copy, then repeat

   Run a full copy while the source stays in use, then repeat it to pick up changes. Later passes usually take far less time than the first. Stop writers for the last pass only if consistency demands it.

4. 04

   Compare before you switch

   Compare object counts and total sizes per prefix on both sides, and spot-check checksums. Keep the OSS bucket until the new clients have run for a full business cycle.

5. 05

   Mind the limits

   STACKIT documents a maximum object size of 5 TB, 1,000 buckets per project and 500 MB/s of upload and download bandwidth per project. A very large bucket needs a plan for the duration of the copy.

Before you apply anything

• Pin the provider

  The run warns that no lock file pins the alicloud provider, which caps every unit at MEDIUM confidence. Commit .terraform.lock.hcl and run again.

• Answer the region

  The inputs template carries one request that blocks the draft: target.region, with eu01 or eu02 as options. Fill it and run again.

• Name an owner

  The run puts all three buckets into one work package, WP-01, owned by the Storage Architect role. Name the person who holds that role before the copy is scheduled.

• Keep the record

  After you answer the region and record reviews, run the assessment into a new folder and compare it with the first run using stacktoit verify --same-as. Keep both folders, so each change is documented.

Questions about OSS to Object Storage

Sources

• Alibaba Cloud: data migration solutions for various sources (OSS)
• Alibaba Cloud: copy objects with the ossutil cp command
• STACKIT Docs: supported operations on buckets and objects
• STACKIT Docs: manage bucket versioning in Object Storage
• STACKIT Docs: limits of Object Storage
• STACKIT Docs: create and delete Object Storage credentials