Object storage migration to STACKIT

The migration in eight steps

The same order works for every source cloud.

1. 01

   Inventory buckets, consumers and settings

   List every bucket or storage account, who reads and writes it, and the settings on it: versioning, lifecycle rules, encryption, replication, public access. The run reads the settings from your Terraform.

2. 02

   Classify each bucket

   Let the assessment assign a class. In the demo: the Amazon S3 bucket is REDESIGN, the Azure storage account REPLATFORM, the Google bucket RECONFIGURE. The class tells you how much application work to expect.

3. 03

   Resolve what has no counterpart

   Take the flagged settings first, here SSE-KMS encryption, cross-region replication and lifecycle rules, because they decide whether the bucket moves as it is.

4. 04

   Create buckets and access

   Apply the Terraform for buckets and credentials groups. Settings the provider cannot carry arrive as S3 API documents that you apply with an access key.

5. 05

   Copy the current objects

   Choose a tool and a host, run a first copy while writers keep working and verify it. rclone is one example the run names.

6. 06

   Copy history if you need it

   A plain sync copies the current version only. If version history matters, plan the per-version copy separately.

7. 07

   Switch consumers

   Each consumer changes endpoint, region name and credentials, and for Azure its client library. Keep the source untouched until the target is verified.

8. 08

   Verify, accept, retire

   Compare key counts, bytes and sample content, then retire the source after acceptance.

Three buckets, three clouds

The input of the run: an Amazon S3 bucket with versioning and SSE-KMS, an Azure storage account with one container, a Google Cloud Storage bucket with versioning and a lifecycle rule. Written for this page.

resource "aws_s3_bucket" "media" {
  bucket = "acme-media-assets"
}

resource "aws_s3_bucket_versioning" "media" {
  bucket = aws_s3_bucket.media.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "media" {
  bucket = aws_s3_bucket.media.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "azurerm_storage_account" "files" {
  name                     = "acmefilesgwc"
  resource_group_name      = azurerm_resource_group.files.name
  location                 = azurerm_resource_group.files.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
}

resource "azurerm_storage_container" "invoices" {
  name                  = "invoices"
  storage_account_id    = azurerm_storage_account.files.id
  container_access_type = "private"
}

resource "google_storage_bucket" "reports" {
  name                        = "acme-reports-eu"
  location                    = "EUROPE-WEST3"
  uniform_bucket_level_access = true

  versioning {
    enabled = true
  }

  lifecycle_rule {
    condition {
      age = 180
    }
    action {
      type = "Delete"
    }
  }
}

• Why one root module

  The run accepts several providers in one folder, so a multi-cloud estate is assessed in a single pass and ordered in one set of waves.

How each bucket was classified

Read from the run of 4 November 2026.

The wording in the right column paraphrases the run. The class names the type of work and authorises nothing.

What the run drafts for the target

Resource blocks of the drafted Terraform, review comments left out, and the S3 API document for versioning. The plan sets versioning through a STACKIT S3 API call because the provider resource has only a name and an object lock.

resource "stackit_objectstorage_bucket" "media" {
  project_id = var.project_id
  name       = "acme-media-assets"
}

resource "stackit_objectstorage_bucket" "files" {
  project_id = var.project_id
  name       = "acmefilesgwc-invoices"
}

resource "stackit_objectstorage_bucket" "reports" {
  project_id = var.project_id
  name       = "acme-reports-eu"
}

{
  "Status": "Enabled"
}

• Names

  The Azure container became the bucket acmefilesgwc-invoices, formed from account and container name. Check the name rules before you rely on it.

• Credentials

  A credentials group and a key are written per consumer you list in a variable. The run states that a key made in any group reaches every bucket of the project, so keys do not separate buckets: keep the key of the copy on the move host, and use separate projects or bucket policies naming the group where access must differ.

The copy plan for the bucket with history

Steps 3 to 6 of the data-copy file the run wrote for the Amazon S3 bucket, without the markup comments that tag each step.

| 3 | Copy the current object of every key (sketch: `rclone copy aws-source:acme-media-assets stackit-s3:acme-media-assets --checksum`, with a remote for each side). | DEFINED |
| 4 | Copy the version history: a plain sync copies the current version only. Versioning must be enabled on the target before the first object lands. Each earlier version is read with its version id (`aws s3api list-object-versions`, `get-object --version-id`) and written oldest first, so the newest becomes the current version. The version ids of the source cannot be kept and the last-modified time becomes the copy time. | DEFINED |
| 5 | Recreate the delete markers: a key whose latest source entry is a delete marker is written and then deleted on the target (`aws s3api delete-object` without a version id creates the marker). Whether STACKIT creates a marker this way is not verified. | DEFINED |
| 6 | Verify: the number of keys and bytes of every prefix equal on both sides, the number of versions and delete markers per key equal; a sample read from the target with an access key of a credentials group (`rclone check`, `aws s3api head-object`). An ETag is not compared (multipart and encrypted objects differ). | DEFINED |

• Only the AWS bucket got steps

  In this run the data steps and the versioning call were written for the Amazon S3 bucket only. The Azure account and the Google bucket are listed as stateful units with the mechanism open, and the README names rclone. The Google bucket's versioning is flagged as a warning, but no versioning document was written for it. Use the rclone steps and checks of the AWS plan as a template; the version-history steps use AWS commands and do not apply as written.

Differences that bite in practice

Each item is documented by the vendor or stated in the run.

• Version history does not travel with a plain copy

  Amazon S3 keeps versions with version IDs and inserts delete markers on delete. The run states that a plain sync copies the current version only, that version IDs cannot be kept and that the last-modified time becomes the copy time.

• Google noncurrent versions are identified by generation

  Cloud Storage keeps replaced objects as noncurrent versions with their generation numbers. Decide if you need them on STACKIT before you plan a copy.

• SSE-KMS has no equivalent

  The run reports that STACKIT has no SSE-KMS integration and answered aws:kms with HTTP 501 in a probe, so the draft does not carry the setting. Its documented modes are platform-managed AES256 and SSE-C, where the client supplies the key.

• Geo-replication does not follow

  Azure GRS copies data asynchronously to a secondary region. The run states that STACKIT Object Storage replicates within the region across three availability zones and has no managed cross-region replication, so a second copy needs its own sync job.

• Azure is not an S3 service

  Blob containers have a different API and authentication. Plan application changes, not just a new endpoint. The AzCopy page documents S3 to Blob; use an S3-capable copy tool such as rclone for the other direction.

• Lifecycle rules are not drafted for the Google bucket

  The run lists the rule as not carried and writes no S3 API document for it. Your team can write one in the shape of the lifecycle document the run produces for other buckets.

Decisions for your architects

What your team settles before the copy starts.

• Copy tool and host

  Data movement is DECISION REQUIRED for all three units. It depends on size, change rate and tolerated downtime, none of which the source states.

• Write freeze

  The window is UNKNOWN until the customer states it, and the runbook assumes none.

• Encryption model

  Pick AES256 or SSE-C, and document who holds the keys.

• Consumer changes

  List every application, SDK, signed URL and connection string that touches each bucket or account.

Questions storage teams ask

Sources

• STACKIT documentation: Object Storage
• STACKIT documentation: Object Storage encryption
• STACKIT documentation: bucket versioning
• Amazon S3 documentation: S3 Versioning
• Google Cloud documentation: Object Versioning
• Microsoft Learn: Azure Storage data redundancy
• Microsoft Learn: Copy data from Amazon S3 with AzCopy