Amazon S3 → Backblaze B2
Move buckets, object keys, and binary content, checksums, etags, and integrity evidence, metadata, tags, and content headers, versions and delete markers, acls, bucket policy, and public access, encryption and customer-managed keys, lifecycle rules and storage classes, cors, events, and application integrations from Amazon S3 to Backblaze B2 with a reversible cutover, explicit exception ledger, and evidence-backed verification.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Amazon S3
- Exceptional durability, scale, ecosystem reach, and storage-class breadth make it an industry default
- Managed sync, sharing, version history, and access controls reduce file-server work
- Policies, networking, replication, lifecycle rules, and request pricing are powerful but intricate
- Shared links, permissions, comments, and ownership models do not map cleanly
Backblaze B2
- Straightforward object storage and predictable economics offer strong value for backups and large files
- Managed sync, sharing, version history, and access controls reduce file-server work
- Its regional footprint and surrounding cloud-service ecosystem are narrower than hyperscale alternatives
- Shared links, permissions, comments, and ownership models do not map cleanly
Backblaze B2: Straightforward object storage and predictable economics offer strong value for backups and large files. This removes a major source-side concern: Policies, networking, replication, lifecycle rules, and request pricing are powerful but intricate.
What you lose: Exceptional durability, scale, ecosystem reach, and storage-class breadth make it an industry default. What you inherit: Its regional footprint and surrounding cloud-service ecosystem are narrower than hyperscale alternatives.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to 500 TB, 500 million objects, 100 buckets, and 10 PB of monthly transfer
- Administrators control both Amazon S3 and Backblaze B2, including billing, identity, APIs, integrations, and export permissions.
- Amazon S3 remains intact and recoverable until Backblaze B2 completes one representative operating cycle.
- A production-shaped pilot includes every object type, access class, edge case, and failure path.
- The migration team preserves stable source identifiers and records durable evidence for every blocking check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Buckets, object keys, and binary content | partial | critical | Object bytes can move while namespace, region, naming limits, and multipart behavior differ. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Map buckets, object keys, and binary content explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Checksums, ETags, and integrity evidence | partial | critical | ETags are not universal content hashes and checksum support varies by upload and provider. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Map checksums, etags, and integrity evidence explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Metadata, tags, and content headers | partial | high | User metadata, tags, content type, disposition, encoding, and cache headers require explicit preservation. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Map metadata, tags, and content headers explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Versions and delete markers | partial | critical | Version IDs, delete markers, retention, and restore semantics are provider-specific. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Map versions and delete markers explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| ACLs, bucket policy, and public access | manual | critical | Identity principals, ACLs, policy languages, public controls, and inherited access do not map safely. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Inventory and rebuild acls, bucket policy, and public access, then test normal, edge, failure, and rollback behavior. |
| Encryption and customer-managed keys | manual | critical | Key services, encryption headers, rotations, grants, and audit ownership change. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Inventory and rebuild encryption and customer-managed keys, then test normal, edge, failure, and rollback behavior. |
| Lifecycle rules and storage classes | manual | high | Transition timing, minimum duration, retrieval cost, and supported storage tiers differ. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Inventory and rebuild lifecycle rules and storage classes, then test normal, edge, failure, and rollback behavior. |
| CORS, events, and application integrations | manual | critical | CORS rules, notifications, queues, functions, and event schemas require replacement. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Inventory and rebuild cors, events, and application integrations, then test normal, edge, failure, and rollback behavior. |
| Signed URLs and S3 API compatibility | partial | critical | Endpoints, regions, signature behavior, unsupported API operations, and URL lifetimes can change clients. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Map signed urls and s3 api compatibility explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Replication, inventory, analytics, and billing history | lost | high | Provider-native reports, replication state, access logs, and cost history do not transfer as services. A successful bulk job therefore does not prove semantic parity between Amazon S3 and Backblaze B2. | Archive replication, inventory, analytics, and billing history as dated source evidence and define the new destination baseline. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Amazon S3: Buckets, object keys, and binary content | Backblaze B2: approved buckets, object keys, and binary content representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for buckets, object keys, and binary content. |
| Amazon S3: Checksums, ETags, and integrity evidence | Backblaze B2: approved checksums, etags, and integrity evidence representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for checksums, etags, and integrity evidence. |
| Amazon S3: Metadata, tags, and content headers | Backblaze B2: approved metadata, tags, and content headers representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for metadata, tags, and content headers. |
| Amazon S3: Versions and delete markers | Backblaze B2: approved versions and delete markers representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for versions and delete markers. |
| Amazon S3: ACLs, bucket policy, and public access | Backblaze B2: approved acls, bucket policy, and public access representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for acls, bucket policy, and public access. |
| Amazon S3: Encryption and customer-managed keys | Backblaze B2: approved encryption and customer-managed keys representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for encryption and customer-managed keys. |
| Amazon S3: Lifecycle rules and storage classes | Backblaze B2: approved lifecycle rules and storage classes representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for lifecycle rules and storage classes. |
| Amazon S3: CORS, events, and application integrations | Backblaze B2: approved cors, events, and application integrations representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for cors, events, and application integrations. |
| Amazon S3: Signed URLs and S3 API compatibility | Backblaze B2: approved signed urls and s3 api compatibility representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for signed urls and s3 api compatibility. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Amazon S3 data, configuration, access, and operating evidence before any destination write.
- Export every available Amazon S3 object and binary in scope, including buckets, object keys, and binary content, checksums, etags, and integrity evidence, metadata, tags, and content headers, versions and delete markers.
- Capture configuration and runtime dependencies for acls, bucket policy, and public access, encryption and customer-managed keys, lifecycle rules and storage classes, cors, events, and application integrations.
- Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
- Hash immutable exports, record tool versions and commands, and transform working copies only.
Proof to capture: A signed manifest accounts for every scoped record class, configuration object, binary, count, total, exception, and hash.
Identity, schema, and disposition registry
Preserve stable identity and make every mapping or exclusion reviewable.
- Inventory source types, identifiers, owners, states, and access.
- Define one approved destination representation or explicit archive decision.
- Reject unmapped critical items and produce an exception ledger.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Dependency-ordered migration package
Load prerequisite identities and configuration before dependent records and runtime actions.
- Normalize encoding, timestamps, identifiers, nulls, and destination limits.
- Run a representative pilot and retain request, response, and rejection evidence.
- Reconcile the final delta before enabling destination production writers.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
A completed migration hides missing or altered buckets, object keys, and binary content
Headline counts look plausible while semantic, access, or relationship checks fail.
- Consequence
- The destination becomes authoritative with incomplete or misleading business data.
- Mitigation
- Reconcile by type, state, owner, access class, and representative record rather than total count alone.
Stop if: Any critical item lacks a verified destination, approved transformation, explicit exclusion, or recoverable archive.
Amazon S3 and Backblaze B2 both perform production actions
Users, schedules, webhooks, integrations, or traffic continue changing both systems.
- Consequence
- State diverges or customers receive duplicate, contradictory, or unsafe actions.
- Mitigation
- Freeze source writers and transfer one production owner at a time with an approved rollback.
Stop if: An unapproved source writer or destination duplicate action appears after the freeze.
Destination access or security is broader than approved
A representative restricted user can read, change, export, or trigger an unauthorized item.
- Consequence
- Confidential, regulated, financial, or security-sensitive data is exposed or changed.
- Mitigation
- Apply least privilege before bulk loading and test every access class using ordinary identities.
Stop if: Any unauthorized read, write, export, administrative action, or secret access succeeds.
Do the work in this order.
- Days 1–4 · inventory
Inventory and decisions
8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting- Inventory Amazon S3 data, configuration, identities, integrations, limits, and billing.
- Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.
Depends on: Amazon S3 and Backblaze B2 administrator access
Stop / go checkpointExport?
Go when: Every critical item and production action has an owner and disposition.
Stop when: Authority, retention, billing, access, or system ownership is unclear.
- Days 3–8 · backup
Backup and reconcile
8–20 hours active2–5 days elapsedProvider export processing waiting- Create immutable data, configuration, binary, and audit exports.
- Reconcile source counts, totals, sizes, access classes, and hashes.
Depends on: Approved inventory and retention location
Stop / go checkpointTransform?
Go when: The signed source manifest and exports agree.
Stop when: Any critical dataset, binary, configuration, or recovery path is absent.
- Days 6–20 · pilot
Map, transform, and pilot
25–70 hours active5–12 days elapsedDestination processing and owner review waiting- Configure Backblaze B2 and transform a production-shaped pilot.
- Test normal records, every feature class, edge cases, permissions, failures, and rollback.
Depends on: Verified source backup and approved mapping registry
Stop / go checkpointScale?
Go when: Every pilot mapping and blocking verification check passes.
Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.
- Days 18–35 · cutover
Bulk load, final delta, and switch
20–55 hours active2–8 days elapsedImports, propagation, indexing, or synchronization waiting- Freeze production writes and automated actions in Amazon S3.
- Apply and reconcile the final delta, switch ownership to Backblaze B2, and run all blocking checks.
Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback
Stop / go checkpointOpen production?
Go when: Backblaze B2 is the sole production owner and every critical exception is resolved.
Stop when: A source writer remains active, a blocking check fails, or rollback is unavailable.
- Days 25–45 · observe
Observe and close
9–19 hours active7–14 days elapsedRepresentative operating-cycle evidence waiting- Monitor correctness, access, failures, latency, delivery, cost, and user outcomes.
- Sign the verification report and close rollback only after stable evidence.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the approved observation period.
Stop when: Data, access, delivery, routing, cost, or business results regress.
Cut over with a way back.
Cutover
Make Backblaze B2 the only production system without losing the final Amazon S3 delta.
- Freeze user, integration, schedule, and API writes in Amazon S3.
- Capture and reconcile the final source delta against the last verified checkpoint.
- Apply the approved delta and configuration changes to Backblaze B2.
- Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
- Run every blocking verification check and keep the source intact.
Proof to capture: Backblaze B2 alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.
Rollback
Return production ownership to Amazon S3 without losing destination-era changes.
- Stop new user, integration, schedule, and API writes in Backblaze B2.
- Restore prior Amazon S3 traffic, domains, credentials, automation, and integration ownership.
- Export and classify the Backblaze B2 post-cutover delta.
- Apply safe destination-era changes back to Amazon S3 without duplicating actions.
- Run the same blocking checks against the restored source.
Proof to capture: Amazon S3 again owns production with current data and no duplicate destination action.
- Unexplained critical count, value, relationship, or checksum variance
- Missing, corrupted, or exposed critical data
- Duplicate production action or unresolved split-brain state
- Failed access, security, delivery, routing, performance, or integration check
- A critical feature has no safe destination replacement or rollback path
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Buckets, object keys, and binary content reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for buckets, object keys, and binary content. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Buckets, object keys, and binary content ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-02Blocking | Checksums, ETags, and integrity evidence reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for checksums, etags, and integrity evidence. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Checksums, ETags, and integrity evidence ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-03Blocking | Metadata, tags, and content headers reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for metadata, tags, and content headers. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Metadata, tags, and content headers ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-04Blocking | Versions and delete markers reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for versions and delete markers. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Versions and delete markers ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-05Blocking | ACLs, bucket policy, and public access reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for acls, bucket policy, and public access. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | ACLs, bucket policy, and public access ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-06Blocking | Encryption and customer-managed keys reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for encryption and customer-managed keys. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Encryption and customer-managed keys ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-07 | Lifecycle rules and storage classes reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for lifecycle rules and storage classes. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Lifecycle rules and storage classes ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-08Blocking | CORS, events, and application integrations reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for cors, events, and application integrations. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | CORS, events, and application integrations ledger with counts, exceptions, sample IDs, and owner sign-off. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check and exception.
- Create final Amazon S3 exports and archive verification, access, financial, and rollback evidence.
- Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
- Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
- Keep the source intact and read-only through the approved legal and operational retention window.
- Cancel paid plans only after billing, legal, security, evidence, and recovery review.
- Schedule the next Backblaze B2 backup, restore test, access review, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
Backblaze reports that CloudSpot moved 700TB and more than 120 million image files from Amazon S3 to B2 in six days without disrupting its photography platform. The vendor attributes the project to storage costs that had begun constraining product decisions and reports more than $10,000 in immediate monthly savings plus a 90% reduction in transfer costs. The source is promotional, but it provides unusually specific scale, timing, and business impact.
- Benchmark a representative set of image reads and writes before moving hundreds of millions of production objects.
- Separate one-time transfer expense from steady-state storage and egress savings when calculating the migration payback.
- A six-day transfer at 700TB scale was possible without stopping the customer-facing service.
- Lower storage costs changed product economics enough for CloudSpot to restore a previously abandoned free migration feature.
Backblaze's Nodecraft case study says the gaming platform migrated 23TB from Amazon S3 to B2 in seven hours with no service disruption. Nodecraft kept Cloudflare as its delivery layer, using the Bandwidth Alliance relationship to eliminate egress charges between storage and CDN. The vendor reports equivalent performance, storage at roughly one fifth of the former cost, and an overall 85% monthly reduction in storage and egress expense.
- Model the destination together with the CDN path because free or discounted inter-provider egress can dominate the result.
- Test restore latency for the largest game-state objects before assuming S3-compatible APIs guarantee equivalent user experience.
- The migration was small relative to CloudSpot but completed in hours while the service stayed available.
- Most of the reported savings depended on the combined Backblaze and Cloudflare architecture, not storage price alone.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- Amazon S3: official portability and migration documentationAccessed 2026-07-20
- Backblaze B2: official portability and migration documentationAccessed 2026-07-20