Migrate Wasabi to Cloudflare R2 with RcloneView

April 9, 2026 · 5 min read

Senior Engineer

Both Wasabi and Cloudflare R2 are S3-compatible and marketed as low-cost alternatives to AWS S3, but their pricing models differ in important ways — RcloneView handles the migration between them with a visual interface.

Wasabi offers hot cloud storage at $6.99/TB/month with no egress fees, but enforces a 90-day minimum storage duration and a minimum monthly charge. Cloudflare R2 charges $0.015/GB/month (roughly $15.36/TB) with zero egress fees and no minimum storage duration. For workloads with frequent data retrieval or short-lived objects, R2 can be significantly cheaper. RcloneView connects to both as S3-compatible remotes and provides a straightforward migration path.

Manage & Sync All Clouds in One Place

RcloneView is a cross-platform GUI for rclone. Compare folders, transfer or sync files, and automate multi-cloud workflows with a clean, visual interface.

One-click jobs: Copy · Sync · Compare
Schedulers & history for reliable automation
Works with Google Drive, OneDrive, Dropbox, S3, WebDAV, SFTP and more

WindowsmacOSLinux

Get Started Free →

Free core features. Plus automations available.

Why Migrate from Wasabi to Cloudflare R2

Both providers eliminate egress fees, which is their main selling point over AWS S3. The decision to migrate typically comes down to:

Minimum storage duration: Wasabi charges for at least 90 days of storage per object, even if you delete it sooner. R2 has no minimum, making it better for transient or frequently replaced data.
CDN integration: R2 integrates natively with Cloudflare's CDN network, enabling instant public access to stored objects through a Cloudflare domain without additional configuration.
Workers integration: If your application uses Cloudflare Workers, R2 provides zero-latency access from edge compute.
Pricing at scale: For storage-heavy workloads, Wasabi's flat per-TB rate may be cheaper. For workloads with high API call volume, R2's pricing model (free for the first 10 million Class B requests per month) may win.

Setting Up Both Remotes

Wasabi Remote

Open RcloneView's Remote Manager and add an S3-compatible remote. Select Wasabi as the provider, enter your Wasabi Access Key and Secret Key, and specify the region endpoint (e.g., s3.us-east-1.wasabisys.com). Select the bucket you want to migrate.

Cloudflare R2 Remote

Add another S3-compatible remote and select Cloudflare R2 as the provider. Enter your R2 Access Key ID and Secret Access Key (generated from the Cloudflare dashboard under R2 > Manage R2 API Tokens). The endpoint follows the format https://<account-id>.r2.cloudflarestorage.com. Create a target bucket in the Cloudflare dashboard or let RcloneView create one during setup.

Executing the Migration

Open Wasabi in the left pane and R2 in the right pane. Navigate to the source bucket on Wasabi and the target bucket on R2.

Since both providers use the S3 API, metadata transfer is straightforward — content types, cache-control headers, and custom metadata carry over. RcloneView uses server-side metadata during the transfer, preserving object properties without additional configuration.

For the initial migration, use a copy job. RcloneView compares files using MD5 checksums (both Wasabi and R2 return standard MD5 ETags for non-multipart uploads) and transfers only new or changed files. Multi-threaded transfers with configurable concurrency keep the migration efficient — set transfers to 8-16 for large bucket migrations.

Be aware of Wasabi's minimum storage duration: if objects were uploaded recently (within the last 90 days), you will still be billed for the full 90 days on Wasabi even after deleting them. Plan your migration timeline accordingly — migrate first, verify, then delete from Wasabi after the 90-day window passes.

Migrating Wasabi to Cloudflare R2 in RcloneView

Verifying the Migration

After the transfer, use RcloneView's compare feature to verify every object arrived on R2. Select the Wasabi source and R2 destination and run a folder comparison. Identical objects appear matched; missing or differing objects are highlighted for review.

For additional confidence, run a check operation that computes checksums on both sides. This verifies data integrity at the byte level.

Verifying Wasabi to R2 migration in RcloneView

Post-Migration Cleanup

Once you have verified the migration:

Update application configurations to point to R2 endpoints instead of Wasabi.
Test application access to confirm everything works with R2.
Wait for the 90-day minimum storage period to pass on Wasabi before deleting objects, to avoid early deletion charges.
Delete the Wasabi bucket and deactivate Wasabi access keys.

If you need to run both providers in parallel during the transition, schedule a daily sync job in RcloneView to keep R2 updated with any new objects added to Wasabi.