Migrate Backblaze B2 S3 bucket: Generated downloads

Move object storage from Backblaze B2 S3 bucket to Ample, one component at a time.

Destination verified on Ample: an export query rendered to a CSV artifact stored with metadata in a private bucket and returned only to an authorized caller (401 without token, export=ok rows=3).

Source procedure: Inventory the bucket with rclone size or the B2 dashboard.

Not migrated automatically: B2 file versions, lifecycle rules and application-key restrictions are not migrated.

Cutover

Switch the app's S3_* environment to the Ample bucket with a redeploy, verify reads and writes, keep B2 read-only until confirmed.

Rollback

Keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

Prerequisites

• Authorized access to the Backblaze B2 S3 bucket source and its export tooling
• An inventory of every component in scope and out of scope
• A validated backup or copy before any cutover
• An Ample account token with servers:write, buckets:write

Workflow Steps

1. Inventory the source
   List what Backblaze B2 S3 bucket provides beyond the component you are moving. Out of scope here: B2 file versions, lifecycle rules and application-key restrictions are not migrated.

2. Source step 1
   Inventory the bucket with rclone size or the B2 dashboard

3. Source step 2
   Copy objects with rclone sync from the B2 S3-compatible endpoint to the Ample bucket endpoint using the issued credentials (path-style)

4. Source step 3
   Verify a sample of objects by size and checksum after the copy

5. Create the destination bucket and copy
   Create the bucket, copy with rclone or the S3 CLI in path-style mode using the issued credentials, then pass the credentials to the app as encrypted S3_* variables.

6. Validate before cutover
   Run the app's own checks and, for data, compare counts and checksums; the example checks are the pattern self-tests (/p/generated-downloads).

7. Cut over
   Switch the app's S3_* environment to the Ample bucket with a redeploy, verify reads and writes, keep B2 read-only until confirmed.

8. Rollback
   Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

Success Checks

• Destination app responds on its public URL

  • Kind: http_get
  • Path: /
  • Expect: ample canary express patterns

• Generated-downloads check from the destination example

  • Kind: http_get
  • Path: /p/generated-downloads
  • Expect: see the pattern fixture checks

• Data or object counts and checksums match the source

  • Kind: manual
  • Expect: operator comparison before cutover

Limitations

• Documentation only: nothing is executed automatically and no execution binding is offered.
• The source-side procedure is documented from Backblaze B2 S3 bucket's standard tooling and was not executed in this catalog's evidence; the destination side was verified with the pattern fixture.
• No full source-product parity is claimed: B2 file versions, lifecycle rules and application-key restrictions are not migrated.
• Verified on the node-22 template at s-1vcpu-1gb; region, compliance and request-duration limits are unknown.
• PutObject and GetObject with path-style addressing are verified; bulk copy tooling and other S3 operations are not.