How it works

You're trusting us to move data you can't afford to lose. Here is exactly what runs, where it runs, and how we prove the copy is complete — in enough detail to take to your security review.

Migration job bm-4821

Verifying

Source

AWS S3

s3://prod-archive

Destination

Backblaze B2

b2://prod-archive

First pass 68%

Objects moved

41.2M

Checksums OK

41.2M ✓

Throughput

9.4 Gbit/s

1. 01

   The engines

   A migration runs as a fleet of parallel workers deployed in the cloud, close to your source or destination region. Workers list the source bucket, partition the keyspace, and stream objects concurrently — hundreds of parallel transfers per engine, multiple engines per job.

   Because transfers run between provider backbones rather than through your infrastructure, throughput is bounded by the providers themselves, not by your uplink. Sustained multi-Gbps is normal; petabyte jobs are a matter of days, not months.

   Listing at scale is half the battle: buckets with hundreds of millions of keys are enumerated with parallel prefix scans so the job starts moving data in minutes, not after a day-long listing pass.

2. 02

   The data path

   Objects stream from source to destination through the engine's memory — encrypted in transit with TLS on both legs, never written to disk on our side, never queued in any intermediate storage. The moment an object lands and verifies at the destination, it's gone from the engine.

   We keep transfer metadata — key names, sizes, checksums, timestamps — because that's what the audit report is built from. We do not keep your object contents. Ever.

3. 03

   Object fidelity

   Multipart objects are handled natively, including objects whose multipart ETags don't match a plain MD5 — we verify those with size plus part-level checksums or provider-native hashes.

   Custom metadata, Content-Type and cache headers travel with each object. Storage class is mapped to the closest destination equivalent, and you approve the mapping before the run. We migrate the current version of each object — version-history reconstruction isn't reliable across providers, so where old versions matter we agree a best-effort plan up front. ACLs are mapped to the closest destination model, and anything that can't translate is flagged before the run.

4. 04

   Retries and failure handling

   Transient failures — throttling, 5xx, connection resets — are retried automatically with exponential backoff, up to 10 attempts per object. Rate limits are respected adaptively so your production traffic on the same bucket isn't starved.

   Objects that exhaust retries land on a failure manifest with the exact error per key. The job doesn't silently skip anything: at the end, every source object is accounted for as either verified at the destination or listed with a reason.

5. 05

   Verification and the audit report

   Every object is checksum-verified end to end: the hash read at the source must match the hash confirmed at the destination. Verification is part of the transfer, not an optional pass afterwards.

   The final audit report lists totals and per-prefix detail — objects moved, bytes moved, checksums verified, failures with reasons — in machine-readable form (JSON/CSV) plus a human summary. It's your proof of a complete migration for auditors and your own peace of mind.

6. 06

   Cutover and re-syncs

   Your source stays live during the migration. After the first full pass, delta re-syncs copy whatever changed while the bulk move ran. Re-syncs are included free for 1 week after the first pass — typically several catch-up rounds until you flip your application to the destination.

   After the window, a new catch-up runs as a separate migration at the standard tariff. Most teams cut over within days, well inside the included week.