Enterprise backup licensing scales painfully with data growth, per-front-end-TB, per-VM, or per-workload models compound every year. Open and lower-cost targets (Proxmox Backup Server, Bacula, Bareos, Restic) can dramatically cut recurring spend, but backup is a trust system: the migration is really about proving restores, not moving software.
What actually changes
Backups don’t “migrate” like VMs, you re-protect workloads on the new platform and let the old backups age out. Backup formats, dedup schemes, and catalog metadata are vendor-specific, so there is no meaningful way to convert an old chain into a new one. You stand up the new system, express your existing policies in its own model, and take fresh full backups. Plan for:
- A clean policy inventory: protected workloads, schedules, retention, RPO/RTO, and offsite/immutable copies.
- New agents/integrations for each workload type (hypervisor, DB, file, application-consistent).
- A parallel-run window of at least one full retention cycle so you never have a coverage gap.
Re-modeling the policy layer
Every platform describes the same operations with different nouns, and translating them is most of the design work. A Veeam or NetBackup policy, a Commvault subclient, or a Rubrik SLA Domain each becomes some combination of a job, a schedule, a fileset or backup selection, and a retention or pool definition on the target. Proxmox Backup Server keeps this close to the hypervisor with deduplicated, incremental-forever backups and optional immutability; Bacula splits it across a Director, storage and file daemons, and explicit jobs, filesets, schedules, and pools. Get the backup selections right first, because over-broad includes inflate every backup while missed paths are silent data loss you only discover at restore time. The migration is also a good moment to prune: estates accumulate stale agents and over-generous retention, and every policy you carry forward is config you then have to maintain.
Running old and new side by side
Deploy the new server, proxies, and repositories (including immutable/object storage), then run first full backups on the new platform while keeping the old repository read-only and retained. Run both in parallel, then switch primary schedules once you trust the new system.
Testing, the part that matters
Before trusting it, test restores, not just backups: file-level, full-VM, database, and a complete DR failover. Verify backup windows fit, dedup ratios are acceptable, and immutability/ransomware-recovery works end to end. Confirm RPO/RTO targets are actually met under realistic conditions.
Retention and the old store
Never delete the old backups on day one, retention and legal-hold obligations often require keeping them well past cutover. Keep the incumbent read-only and restorable until every point it holds has aged past your retention and any legal hold, which for compliance data is often measured in years, not weeks. During that overlap, new backups go to the new platform while any restore of pre-cutover data still comes from the old catalog or store, and you decommission the incumbent only after its last obligated recovery point expires. Pulling the old system early to stop paying for it sooner is how teams discover, mid-audit or mid-incident, that a point they were required to keep is gone. That parallel-run overlap is also where the migration actually spends money, so budget for it rather than assuming savings begin at cutover.
Use the TCO calculator to model your backup spend sized on TB protected.