R2 migration playbook: Super Slurper, Sippy, or rclone
Choose an R2 migration path by downtime model, object limits, and verification requirements, then plan a gradual and reversible cutover.
Edited and verified by Orange Book Editorial Team ·
Conclusion first
Evaluate Super Slurper for a one-time bulk copy. Evaluate Sippy when service cannot stop and R2 should copy an object after a miss. Use rclone or a purpose-built tool for very large objects, custom filters, or controlled retries. No path should treat matching ETags as the only proof of success.
Detailed description
- 01Inventory
Record count, bytes, size distribution, metadata, and large objects.
- 02Transfer
Choose a tool by cutover model and object constraints.
- 03Verify
Compare inventories, sample content, and exercise application flows.
- 04Cut over
Canary read traffic and keep the source available for rollback.
Choose among three paths
| Path | Good fit | Important constraint | Verify before release |
|---|---|---|---|
| Super Slurper | One-time bulk copies from S3, GCS, or S3-compatible storage | Primarily for individual objects below 1 TB; it does not change the source | Failure list, separate large-object handling, object count, and bytes |
| Sippy | No downtime: serve from the source on an R2 miss and copy at the same time | Source changes after an object's first copy are not propagated; concurrent misses can fetch more than once | Hot keys, source cost, write window, and remaining cold objects |
| rclone / custom tool | Large objects, filters, renames, throttling, or custom validation | Your team owns concurrency, retries, checkpoints, and auditability | Idempotent reruns, failure recovery, and API limits |
Six-step migration
Freeze a source baseline
Record the bucket, object count, bytes, size distribution, Content-Type, custom metadata, cache headers, lifecycle, and encryption requirements. List objects above 1 TB separately. If writes remain open, record the incremental-sync start time and owner.
Select a cutover model
If writes can freeze for a one-time copy, shortlist Super Slurper. If service must remain online and reads can trigger backfill, shortlist Sippy. Split large objects or custom transformations into rclone or a purpose-built job. Sippy and Super Slurper can work together: one serves misses while the other fills the remaining inventory.
Migrate one controlled prefix
Choose a non-sensitive prefix with representative sizes and repeatable checks. Record start and finish times, source requests and transfer, R2 writes, failed objects, and retry count. Do not point the production domain at R2 as the first step.
Verify five layers
Check: 1. object count; 2. total bytes; 3. keys, Content-Type, cache headers, and custom metadata; 4. sample small, medium, and large objects and compare content digests; 5. exercise real upload, read, range-request, and deletion flows. Multipart behavior can change an ETag after migration, so an ETag is only a clue.
Canary read traffic
Send internal or a small share of reads to R2 first. Observe missing keys, 5xx responses, latency, source fallback, and business errors. Define a rollback switch before changing the domain, and keep the old configuration and source bucket usable.
Close migration and retain a rollback window
After incremental differences reach zero, application checks pass, and the observation window closes, stop source writes or complete the final sync. Deleting the source bucket is a separate, human-approved operation—not part of declaring the migration successful.
Sippy is not continuous two-way synchronization
After an object is first copied into R2, later source changes are not automatically reflected. Freeze source writes for that object or define an explicit incremental-sync and conflict policy.
Completion criteria and rollback triggers
- Inventory differences are explained; failed objects are retried or explicitly excluded.
- Sample digests and application reads pass; ETag equality is not the sole check.
- New writes have one authority, or a tested dual-write/incremental policy exists.
- Read traffic can return to the source if misses, errors, or source cost exceed a threshold.
- Source retention, deletion approver, and final cleanup date are recorded.
After migration, use the R2 production delivery recipe for domains, CORS, and authorization. For selection economics, see R2 compared with S3, OSS, and B2.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.
Guide template: follow one Cloudflare request
A complete Orange Book Guide pattern from outcome and prerequisites to checkpoints.
Add AI capabilities to a normal application only when needed
Treat inference, model gateways, and natural-language search as replaceable modules, not prerequisites for a useful application.