Switch from BYOS to macup Cloud

People switch from BYOS to macup Cloud for a short list of reasons: the bill got unpredictable, the IAM policy drifted, an egress charge arrived they were not expecting, or they simply got tired of being their own storage admin. The good news is that the migration is not destructive. You do not move any bytes by hand. Your history is preserved. You run both destinations in parallel until you trust the new one, then decommission the old one.

Why switch

• Predictable bill. One tier, one monthly price, no egress line item.
• Managed immutability. Object Lock compliance mode is on by default; you do not have to remember to configure it.
• No IAM juggling. No per-Mac users, no rotating keys, no least-privilege policies to maintain.
• No egress surprises. A full restore at 3 AM on a Sunday does not show up on the next invoice as a five-figure shock.

Why you might not switch

Be honest about the case for staying:

• You already own unlimited on-prem storage and the operator who runs it.
• You have strict data-residency requirements that you control directly and cannot delegate.
• Your procurement department has already approved your current provider through a painful process.
• You like the bill you have and do not want to change anything.

If any of those apply, stay on BYOS. The rest of this guide is for the case where switching is the right move.

Step 1 — Add macup Cloud as a second destination

Do not remove BYOS yet. Add macup Cloud as a brand-new destination:

1. Open macup > Preferences > Destinations.
2. Click Add destination.
3. Choose macup Cloud.
4. Pick a capacity tier.
5. Let macup provision the repository.

Detailed steps are in the Back up to macup Cloud article.

Step 2 — Attach the new destination to your backup set

A backup set can write to more than one destination at a time. Attach macup Cloud in addition to the BYOS bucket, not instead of it:

1. Open Backup Sets.
2. Pick the set you are migrating.
3. Open the Destinations tab.
4. Click Add destination on the set and choose the new macup Cloud destination.
5. Leave BYOS attached.

The set now writes every new snapshot to both places.

Step 3 — Wait for the first full snapshot to macup Cloud

The first snapshot to any new destination is a full upload. It does not reuse data from BYOS — content-addressed dedup works within a repository, not across two repositories on two providers. Timing for a first full upload on gigabit:

• 200 GB — about 45 minutes.
• 1 TB — 3 to 4 hours.
• 2 TB — 6 to 8 hours.
• 5 TB — plan overnight.

Subsequent snapshots are incremental and small.

Step 4 — Verify with a restore

A backup is not a backup until you have restored from it. Before you detach BYOS:

1. Pick a non-critical folder — a sub-directory of Documents, a single Lightroom library, a specific project.
2. Start a restore, pointed at macup Cloud as the source.
3. Restore to a scratch location, not over your live working copy.
4. Spot-check a handful of files — open them, check a checksum, play the video.

The Restore a whole folder article walks through the UI. If the restore works, the destination works.

Step 5 — Run both in parallel for a week

Leave both destinations attached for at least seven days. The point is boring: if something about macup Cloud is quietly wrong — a passphrase typo, a permission mistake, a misconfigured retention window — you want a full working week of normal use, normal snapshots, and normal daily verification to surface it while your BYOS history is still intact.

During the parallel week:

• Keep an eye on the Destinations pane. Both should show green, both should show fresh “last snapshot” timestamps.
• If you do a real restore for any reason during the week, do it from macup Cloud. Treat BYOS as the safety net, not the primary.

Step 6 — Detach BYOS from the backup set

Once the week is up and both destinations are healthy:

1. Open Backup Sets → your set → Destinations.
2. Click Detach next to the BYOS destination.

macup stops writing new snapshots to BYOS. Your existing BYOS history is untouched and still readable — detaching from a set does not delete the repository.

Step 7 — Decide the BYOS repository’s fate

You now own a frozen BYOS repository with the last few years of history. Three sensible options:

• Keep it read-only for one snapshot cycle (30-90 days) as an additional offline archive, then delete.
• Export a single restore point — one full snapshot — to cold storage, then delete the BYOS bucket.
• Delete it immediately if you trust the macup Cloud archive and want the bill to stop.

Your BYOS provider bills until the bucket is gone; macup Cloud bills from the day you signed up for the tier. Plan the overlap so you are not double-paying for longer than you meant to.