OtterMigration

OtterMigration is OtterStorage's self-service assisted migration. You connect your source bucket, pick the destination bucket, and we copy the objects for you in the background, on isolated and dedicated infrastructure. You'll see progress in real time and, because the copy is additive, nothing is ever deleted at the destination and you can resume it safely.

What you can migrate

• AWS S3 and any S3-compatible service: Wasabi, Backblaze B2 (S3), MinIO, Cloudflare R2, DigitalOcean Spaces, and more.
• Otter → Otter: move data between two OtterStorage buckets or zones.

The migration copies the current objects from the source to the destination. If you need to keep the version history, enable versioning on the destination bucket before launching the copy.

How it works

Each migration runs in an isolated, disposable container on a dedicated node, separate from the API and from storage. That container reads from your source and writes to your destination bucket, reporting progress and logs to the console. Design principles:

• Additive copy, never a destructive sync: on retry, OtterMigration skips objects that already exist at the destination with a matching checksum and resumes cheaply. It never deletes data at the destination.
• Integrity verification: the transfer checks checksums to guarantee every object arrives intact.
• No downtime: your source stays operational throughout; you can keep both sides live and cut over when it finishes.
• Per-account isolation: you only see and manage your own migrations.

Step 1: create the destination bucket

Buckets are created from the OtterStorage panel. Create the bucket that will receive the data and, if needed, configure it before migrating:

• Enable versioning if you want to keep versions.
• If you need immutability, remember that Object Lock can only be enabled when you create the bucket.
• Choose the right zone and disk technology.

See the create a bucket guide if it's your first time.

Step 2: gather the source credentials

From the source provider you'll need an access key with read permission on the bucket you're migrating, plus its endpoint and region. We recommend creating a temporary, read-only key and revoking it when you're done.

What the OtterMigration form will ask for:

• Source type (AWS S3, S3-compatible, or Otter).
• Endpoint and region of the source (e.g. s3.eu-west-1.amazonaws.com).
• Source bucket and, optionally, a prefix to migrate only one folder.
• Access key and secret key of the source.
• Destination bucket (one of yours) and an optional destination prefix.

Step 3: verify before launching

Before moving a single byte, click Verify. OtterMigration runs a pre-flight check: it confirms it can read from the source and write to the destination with the credentials you provided. If anything is wrong (bad credentials, unreachable endpoint, insufficient permissions), you'll know right away, before any copying starts.

Step 4: launch and follow the progress

When the check passes, click Launch. The detail page shows:

• Progress bar with percentage, objects and bytes transferred, throughput and estimated ETA.
• Live log streaming: if you close and reopen it, it resumes without losing lines.
• Controls: Pause, Resume and Stop the migration at any time.

For security, when you resume a paused migration you'll be asked for the source secret key again (we don't keep it longer than necessary; see below).

Security and privacy

Because you provide credentials for an external service, OtterMigration is designed to minimize the blast radius:

• Credentials encrypted at rest and single-use: they're never returned in any response and never appear in the log (the access key is shown masked; the secret key never is).
• Automatic purge of the secret as soon as the migration finishes or is abandoned.
• Scrubbed logs: anything that looks like a credential is replaced with ***.
• Anti-SSRF protection: the source endpoint is validated to prevent it pointing at internal networks; the node's network only allows egress to the internet and to our storage.
• Account admins only can create and launch migrations.

Limits and cost

• Per-account quotas: there's a cap on concurrent and daily migrations to prevent abuse. If you need to move a very large volume, get in touch.
• Bandwidth limit: you can cap the speed per migration so you don't saturate your network or the source's.
• Source egress: OtterStorage doesn't charge for data ingress. But your source provider (e.g. AWS) usually does charge for egress. Estimate that cost before migrating large volumes out of a hyperscaler.

Best practices

• Use read-only, temporary source credentials; revoke them when you're done.
• Enable versioning at the destination before migrating if history matters to you.
• Start with a small prefix to validate the end-to-end flow, then launch the full bucket.
• Always verify before launching: it catches permission or endpoint errors without spending transfer.
• Cut over when it's done: keep the source live until you confirm the destination is complete (you can relaunch for a final pass that only copies the new objects).

What if I'd rather migrate myself?

OtterMigration is the managed, self-service path inside the console. If you'd rather drive the transfer from your own machine or pipeline, OtterStorage is 100% S3-compatible and you can use rclone, AWS CLI or MinIO Client. There's a step-by-step in the how to migrate from AWS S3 guide.

Frequently asked questions

Is my service interrupted during the migration? +

No. The migration only reads from your source and writes to your destination bucket; both sides stay operational. You can cut your application over to the OtterStorage endpoint once the copy has finished and you've verified it.

What happens if the migration is interrupted halfway? +

You don't lose anything: the copy is additive and never deletes at the destination. On resume or relaunch, OtterMigration skips the objects already copied with a matching checksum and continues where it left off.

Are versions and Object Lock preserved? +

Current objects are copied. To keep history, enable versioning on the destination bucket before migrating. Object Lock must be enabled when you create the destination bucket if you need immutability.

Who can launch a migration? +

Only account admins. Source credentials are encrypted, used once and purged when finished; they're never returned or written to the log.

How much does migrating cost? +

OtterStorage doesn't charge for data ingress. Note that your source provider may charge for egress (this is the case with AWS and other hyperscalers); that cost is billed by the source, not by us.