migrating toBrowse playbooks
← All playbooks
Object storage migration

Backblaze B2 → Cloudflare R2

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 Backblaze B2 to Cloudflare R2 with a reversible cutover, explicit exception ledger, and evidence-backed verification.

Typical timeline15–45 business days70–180 hours active work
Statusneeds review
Source profileBackblaze B2 documentation reviewed 2026-07-20
Destination profileCloudflare R2 documentation reviewed 2026-07-20
Documentation date
Review window
Evidence2 sources
This route needs review.Use it as a planning baseline, then verify the dated sources and test with representative data before production.
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Backblaze B2

Reasons to stay
  • 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
Reasons to leave
  • Its regional footprint and surrounding cloud-service ecosystem are narrower than hyperscale alternatives
  • Shared links, permissions, comments, and ownership models do not map cleanly
New platform

Cloudflare R2

What gets better
  • S3-compatible object storage removes egress fees and integrates directly with Cloudflare's edge platform
  • Managed sync, sharing, version history, and access controls reduce file-server work
What gets worse
  • API differences, ecosystem maturity, and Cloudflare-specific bindings require compatibility testing
  • Shared links, permissions, comments, and ownership models do not map cleanly
Best of the move

Cloudflare R2: S3-compatible object storage removes egress fees and integrates directly with Cloudflare's edge platform. This removes a major source-side concern: Its regional footprint and surrounding cloud-service ecosystem are narrower than hyperscale alternatives.

Worst of the move

What you lose: Straightforward object storage and predictable economics offer strong value for backups and large files. What you inherit: API differences, ecosystem maturity, and Cloudflare-specific bindings require compatibility testing.

Connected catalog

2 destinations are documented from Backblaze B2. Compare nearby routes before committing.

Also from Backblaze B2
Also moving to Cloudflare R2
Jump to a section
01At a glance

Know the shape of the move.

Transfer outcome10 features audited
Transfer outcome distributionClean transfer: 0, Partial transfer: 5, Manual rebuild: 4, Not transferred: 1.
Clean0
Partial5
Manual4
Lost1
Mapping route9 of 9 fields have a destination path

This timeline assumes

  • Up to 500 TB, 500 million objects, 100 buckets, and 10 PB of monthly transfer
  • Administrators control both Backblaze B2 and Cloudflare R2, including billing, identity, APIs, integrations, and export permissions.
  • Backblaze B2 remains intact and recoverable until Cloudflare R2 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.
02What transfers

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Buckets, object keys, and binary contentpartialcriticalObject bytes can move while namespace, region, naming limits, and multipart behavior differ. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Map buckets, object keys, and binary content explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Checksums, ETags, and integrity evidencepartialcriticalETags are not universal content hashes and checksum support varies by upload and provider. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Map checksums, etags, and integrity evidence explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Metadata, tags, and content headerspartialhighUser metadata, tags, content type, disposition, encoding, and cache headers require explicit preservation. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Map metadata, tags, and content headers explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Versions and delete markerspartialcriticalVersion IDs, delete markers, retention, and restore semantics are provider-specific. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Map versions and delete markers explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
ACLs, bucket policy, and public accessmanualcriticalIdentity principals, ACLs, policy languages, public controls, and inherited access do not map safely. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Inventory and rebuild acls, bucket policy, and public access, then test normal, edge, failure, and rollback behavior.
Encryption and customer-managed keysmanualcriticalKey services, encryption headers, rotations, grants, and audit ownership change. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Inventory and rebuild encryption and customer-managed keys, then test normal, edge, failure, and rollback behavior.
Lifecycle rules and storage classesmanualhighTransition timing, minimum duration, retrieval cost, and supported storage tiers differ. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Inventory and rebuild lifecycle rules and storage classes, then test normal, edge, failure, and rollback behavior.
CORS, events, and application integrationsmanualcriticalCORS rules, notifications, queues, functions, and event schemas require replacement. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.Inventory and rebuild cors, events, and application integrations, then test normal, edge, failure, and rollback behavior.
Signed URLs and S3 API compatibilitypartialcriticalEndpoints, regions, signature behavior, unsupported API operations, and URL lifetimes can change clients. A successful bulk job therefore does not prove semantic parity between Backblaze B2 and Cloudflare R2.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 historylosthighProvider-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 Backblaze B2 and Cloudflare R2.Archive replication, inventory, analytics, and billing history as dated source evidence and define the new destination baseline.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Backblaze B2: Buckets, object keys, and binary contentCloudflare R2: approved buckets, object keys, and binary content representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for buckets, object keys, and binary content.
Backblaze B2: Checksums, ETags, and integrity evidenceCloudflare R2: approved checksums, etags, and integrity evidence representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for checksums, etags, and integrity evidence.
Backblaze B2: Metadata, tags, and content headersCloudflare R2: approved metadata, tags, and content headers representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for metadata, tags, and content headers.
Backblaze B2: Versions and delete markersCloudflare R2: approved versions and delete markers representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for versions and delete markers.
Backblaze B2: ACLs, bucket policy, and public accessCloudflare R2: approved acls, bucket policy, and public access representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for acls, bucket policy, and public access.
Backblaze B2: Encryption and customer-managed keysCloudflare R2: approved encryption and customer-managed keys representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for encryption and customer-managed keys.
Backblaze B2: Lifecycle rules and storage classesCloudflare R2: approved lifecycle rules and storage classes representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for lifecycle rules and storage classes.
Backblaze B2: CORS, events, and application integrationsCloudflare R2: approved cors, events, and application integrations representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for cors, events, and application integrations.
Backblaze B2: Signed URLs and S3 API compatibilityCloudflare R2: approved signed urls and s3 api compatibility representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for signed urls and s3 api compatibility.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Backblaze B2 data, configuration, access, and operating evidence before any destination write.

  1. Export every available Backblaze B2 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.
  2. 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.
  3. Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
  4. 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.

Transformation · Version-controlled migration workbook, SQL, or typed transformation code

Identity, schema, and disposition registry

Preserve stable identity and make every mapping or exclusion reviewable.

  1. Inventory source types, identifiers, owners, states, and access.
  2. Define one approved destination representation or explicit archive decision.
  3. 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.

Transformation · Official APIs, provider importers, checksums, and reconciliation scripts

Dependency-ordered migration package

Load prerequisite identities and configuration before dependent records and runtime actions.

  1. Normalize encoding, timestamps, identifiers, nulls, and destination limits.
  2. Run a representative pilot and retain request, response, and rejection evidence.
  3. 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.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Import

A completed migration hides missing or altered buckets, object keys, and binary content

criticalpossible likelihood

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.

Cutover

Backblaze B2 and Cloudflare R2 both perform production actions

criticalpossible likelihood

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.

Verification

Destination access or security is broader than approved

criticalpossible likelihood

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.

06Precise timeline

Do the work in this order.

Estimate forUp to 500 TB, 500 million objects, 100 buckets, and 10 PB of monthly transfer
Total elapsed15–45 business days
Active work70–180 hours
BufferAdd time for large Backblaze B2 exports, destination rate limits, unsupported features, identity exceptions, regulated data, or a strict downtime objective.
01
Days 1–4Inventory and decisions2–4 days
02
Days 3–8Backup and reconcile2–5 days
03
Days 6–20Map, transform, and pilot5–12 days
04
Days 18–35Bulk load, final delta, and switch2–8 days
05
Days 25–45Observe and close7–14 days
  1. Days 1–4 · inventory

    Inventory and decisions

    8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting
    • Inventory Backblaze B2 data, configuration, identities, integrations, limits, and billing.
    • Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.

    Depends on: Backblaze B2 and Cloudflare R2 administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item and production action has an owner and disposition.

    Stop when: Authority, retention, billing, access, or system ownership is unclear.

  2. 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 checkpoint

    Transform?

    Go when: The signed source manifest and exports agree.

    Stop when: Any critical dataset, binary, configuration, or recovery path is absent.

  3. Days 6–20 · pilot

    Map, transform, and pilot

    25–70 hours active5–12 days elapsedDestination processing and owner review waiting
    • Configure Cloudflare R2 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 checkpoint

    Scale?

    Go when: Every pilot mapping and blocking verification check passes.

    Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.

  4. 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 Backblaze B2.
    • Apply and reconcile the final delta, switch ownership to Cloudflare R2, and run all blocking checks.

    Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback

    Stop / go checkpoint

    Open production?

    Go when: Cloudflare R2 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.

  5. 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 checkpoint

    Close rollback?

    Go when: No trigger occurs during the approved observation period.

    Stop when: Data, access, delivery, routing, cost, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Cloudflare R2 the only production system without losing the final Backblaze B2 delta.

Recommended window: A low-volume weekday morning with platform, data, security, networking, finance, and business owners available.

  1. Freeze user, integration, schedule, and API writes in Backblaze B2.
  2. Capture and reconcile the final source delta against the last verified checkpoint.
  3. Apply the approved delta and configuration changes to Cloudflare R2.
  4. Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: Cloudflare R2 alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Backblaze B2 without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, keys, or retention settings are changed.

  1. Stop new user, integration, schedule, and API writes in Cloudflare R2.
  2. Restore prior Backblaze B2 traffic, domains, credentials, automation, and integration ownership.
  3. Export and classify the Cloudflare R2 post-cutover delta.
  4. Apply safe destination-era changes back to Backblaze B2 without duplicating actions.
  5. Run the same blocking checks against the restored source.

Proof to capture: Backblaze B2 again owns production with current data and no duplicate destination action.

Rollback immediately when
  • 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
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingBuckets, object keys, and binary content reconciliationCompare 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-02BlockingChecksums, ETags, and integrity evidence reconciliationCompare 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-03BlockingMetadata, tags, and content headers reconciliationCompare 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-04BlockingVersions and delete markers reconciliationCompare 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-05BlockingACLs, bucket policy, and public access reconciliationCompare 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-06BlockingEncryption and customer-managed keys reconciliationCompare 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-07Lifecycle rules and storage classes reconciliationCompare 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-08BlockingCORS, events, and application integrations reconciliationCompare 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.
09Post-migration cleanup

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.

  1. Create final Backblaze B2 exports and archive verification, access, financial, and rollback evidence.
  2. Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
  3. Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
  4. Keep the source intact and read-only through the approved legal and operational retention window.
  5. Cancel paid plans only after billing, legal, security, evidence, and recovery review.
  6. Schedule the next Cloudflare R2 backup, restore test, access review, and migration-playbook review.
Sources and evidence

Verify against the primary material.

Platform behavior changes. Check these sources and the review dates above before executing a production migration.

  1. Backblaze B2: official portability and migration documentationAccessed 2026-07-20
  2. Cloudflare R2: official portability and migration documentationAccessed 2026-07-20