Most teams pick a backup platform the wrong way: they compare data-protection feature grids, tallying which product supports which hypervisor, which database agent, and which cloud tier. That comparison looks rigorous and misses the point, because a backup platform is not a feature set you buy, it is a promise to restore that you have to prove. The move off Veeam, NetBackup, Commvault, or Rubrik is decided by whether the new system meets your recovery objectives at your data volume with the operations staff you actually have. This guide gives you the rubric that gets you there instead of a longer checklist.
Write down the recovery targets first
Before you shortlist anything, put four things on paper. Your recovery objectives, per workload class: the RPO and RTO you are actually held to, which differ for a tier-one database and an archive file share. Your protected data volume and its growth rate, because that is what every capacity-based license and every backup window scales against. Your workload mix: virtual machines, databases, physical servers, and applications each need their own agent or integration, and the mix determines how much of a platform you will really use. And your retention and legal-hold obligations, which for compliance data are measured in years and dictate how long the old store must survive. Those four facts decide the answer more than any product’s feature count.
What to weigh, in order
- RPO and RTO targets. How fresh a recovery point you need and how fast you must be back up sets the floor. Aggressive objectives demand replication and fast restore paths; relaxed ones open up simpler, cheaper designs.
- Data volume and growth. This is what capacity-based pricing punishes and what sizes your repositories, dedup, and backup windows. A platform that is fine today can be expensive or too slow two growth cycles from now.
- Workload mix. VM-only estates, database-heavy estates, and estates full of physical and application servers each favor different tools. Match the platform to what you protect, not to the broadest agent catalog.
- Immutability and ransomware resilience. Whether you need immutable, air-gapped, or object-locked copies is now a first-order requirement, not an add-on, and not every target does it the same way.
- Retention and legal hold. Long, regulated retention shapes both storage cost and how long you must keep the incumbent restorable in parallel, which is a real line item, not a footnote.
- In-house ops capacity. An open target shifts cost from license to the people who assemble and run it. Be honest about whether your team can stand up and operate the pieces at the scale you need.
Which platform fits which estate
Score your estate against the criteria above, then use these as starting points rather than conclusions. Estates that are largely virtualized, and especially Proxmox or KVM shops, look first at Proxmox Backup Server, which keeps protection close to the hypervisor with deduplicated, incremental-forever backups and optional immutability, and gives you a coherent product rather than a kit to assemble. Teams with a genuinely mixed estate of VMs, databases, physical hosts, and applications, and the operational appetite to build and run the pieces, look at Bacula, which splits the work across a Director, storage and file daemons, and explicit jobs, filesets, schedules, and pools, buying flexibility at the cost of more to wire together and maintain. Both move recurring license spend toward your own operations, so the right one depends on how much assembly your team can carry, not on which has more integrations on paper.
Mistakes that leave you unable to restore
The errors here are unusually costly because you discover them at the worst moment. The first is testing that backups complete instead of testing that restores work: file-level, full-VM, database, and a full DR failover are the real acceptance tests, and a green backup job proves nothing about recoverability. The second is under-scoping backup selections: over-broad includes inflate every backup while missed paths are silent data loss you only find at restore. The third is pulling the old system early to stop paying for it, then discovering mid-audit or mid-incident that a point you were required to keep is gone. A fourth is treating immutability and ransomware recovery as a checkbox rather than exercising the end-to-end recovery from an immutable copy before you trust it.
Confirm it can restore, then commit
Turn your top candidate into a proof with written acceptance criteria and run old and new side by side. Stand up the new server, proxies, and repositories including immutable or object storage, take first full backups on the new platform, and keep the incumbent read-only and retained through at least one full retention cycle so you never open a coverage gap. Prove restores across every workload class, run a complete DR failover, confirm backup windows fit and dedup ratios hold, and verify RPO and RTO are met under realistic conditions. Budget for the parallel-run overlap, since that is where the migration actually spends money, and model your spend sized on TB protected with the calculator. Decommission the incumbent only after its last obligated recovery point has aged out, never on cutover day.