If you have been told to buy Commvault, the first thing you will discover is that “Commvault” is not one thing. The portfolio has evolved several times in recent years, and the names on today’s website will not all be there in two years.

That is survivable, because the decisions underneath the names barely move. Get these four right and the product name follows almost mechanically — and when the packaging changes again, your requirements still make sense.

Decision 1: Where does it run?

Three answers, and they are not interchangeable.

Software you deploy and operate. Full control over topology, storage tiering and recovery sequencing. The right answer when you have data residency rules a shared service cannot satisfy, unusual workloads, or an existing team with the expertise.

A subscription from Commvault. The vendor runs the infrastructure; you consume it per user, per VM or per terabyte. Clean procurement, fast to stand up, and it suits estates that are mostly SaaS applications and virtual machines.

Delivered by a partner. A third party owns the licensing and the operations and hands you an outcome. This is a different question from which product you buy, and it is covered properly in our article on Commvault Backup-as-a-Service.

Answer this first, because it constrains everything below it. An estate with a hard on-premises requirement for one regulated workload cannot be solved entirely by a subscription, no matter how the rest of it looks.

Decision 2: What has to be protected?

Make the list before you look at any product page, and make it exhaustive. Most scoping failures are omissions, not estimates.

Work through these in order:

• Virtual machines — hypervisor, host count, VM count, growth rate.
• Physical servers — easy to forget, and usually the oldest and least documented things you own.
• Databases — engine and version for each, because support varies and the unusual ones drive the decision.
• SaaS applications — Microsoft 365, Salesforce, Dynamics. Protected separately from infrastructure, priced separately, and frequently assumed to be the vendor’s problem. They are not.
• Containers — Kubernetes estates need their own treatment, and persistent volumes are where the data actually lives.
• Endpoints — only if laptops hold anything that is not synced elsewhere. Often a large line item for a small amount of real risk.
• Cloud-native storage and object data — the buckets nobody listed because no server is attached to them.

Two questions sharpen this list. Which of these would stop the business within 24 hours of being unavailable? And which would survive being restored from a copy that is a day old? The answers separate what needs continuous protection from what needs a nightly job, and that split drives more of the cost than any license negotiation.

Decision 3: Where does the data land?

Backup storage is usually the larger half of the bill over three years, and it is the half most often sized by habit.

The variables are retention, tiering and egress. Retention is normally set by a regulator or an auditor, so start there rather than at a default of thirty days. Tiering decides whether the older copies sit on fast storage you are paying premium rates for; most estates only need fast recovery on recent data. Egress is the one people miss — cloud storage is cheap to fill and expensive to empty, and a full-estate recovery is the single largest egress event you will ever have.

Run the arithmetic on a real recovery, not a steady state. A plan that is affordable until the day you need it is not a plan.

Decision 4: What recovery do you have to be able to prove?

This is the decision that separates a backup purchase from a resilience purchase, and it is the one most often deferred.

Backing data up and being able to recover it are different claims, and only the second one matters to a board, an insurer or a regulator. The questions worth answering before you sign:

1. How fast, for what? Not a single recovery time objective across the estate — a tiered one. Everything is not equally urgent, and pretending otherwise is how organizations overpay.
2. Can you test it without disruption? If recovery testing requires an outage window, it will be scheduled, deferred, and eventually skipped.
3. Does recovery survive a compromised environment? If an attacker with domain credentials can reach the backups, the backups are part of the incident rather than the answer to it. Isolation and immutability belong in the requirement from the start, not in a later project.
4. Can you prove it to a third party? Insurers and auditors increasingly want evidence of tested recovery, not a policy document.

A note on product names

Because the packaging moves, resist the urge to specify by product name in an internal business case. Specify by requirement — “protects these workloads, retains for this long, recovers these systems in this time, isolated from production credentials” — and let the product name be a procurement detail. Business cases written that way survive a rebrand; ones written around a product name have to be redone.

Where Arrosoft fits

We implement and run Commvault for organizations from thirty to thirty thousand endpoints, and most of our engagements start with the four decisions above rather than with licensing. Where it matters, Arrosoft AirGap integrates with Commvault to keep an isolated, immutable copy out of reach of a compromised environment.

If you are earlier than that — still deciding whether to run it yourself at all — the companion question is who operates it, which we cover separately.

A scoping conversation is usually a better use of an hour than a product comparison.