VMware Site Recovery Manager to VMware Live Site Recovery: The Complete Guide

SRM TO VMWARE LIVE SITE RECOVERY

A Consult Circle guide to what the rebrand actually changed, how VMware Live Site Recovery fits into VMware Live Recovery, and what it means for a DR estate built on Site Recovery Manager.

If you run Site Recovery Manager, the first thing worth establishing is that you have not lost your DR platform. Broadcom rebranded Site Recovery Manager as VMware Live Site Recovery and brought it, together with the former Cloud Disaster Recovery, under the VMware Live Recovery umbrella to align with the Cloud Foundation direction. The product continued, the version numbering continued, and the recovery plans you built still work.

That is genuinely reassuring and it is also where most articles on the subject stop, which is not much help to anyone with a real DR estate. The questions that matter are different: what changed underneath the name, what the licensing move means, how it relates to the cyber recovery half of the family, what is new in the current releases, and whether the architecture you designed against SRM six years ago is still the right one.

This guide covers all of that. It is written for the person who owns disaster recovery for a VMware estate and needs to know what to do differently, if anything, and what to plan for.

What this guide covers

• What the rebrand changed and what it did not
• The VMware Live Recovery family and how the two halves relate
• What VMware Live Site Recovery actually is, architecturally
• The three replication options and how to choose
• What is new in the 9.0 release stream
• Licensing and what it means commercially
• Whether your existing design still holds
• Planning your next move, with a checklist

What the Rebrand Changed

Broadcom rebranded both Site Recovery Manager and Cloud Disaster Recovery, bringing them under the VMware Live Recovery family to align with the Cloud Foundation vision. Site Recovery Manager became VMware Live Site Recovery. Cloud Disaster Recovery became VMware Live Cyber Recovery.

Practically, the effects are modest and worth stating plainly so nobody spends time looking for changes that are not there.

• The product architecture is unchanged. It remains an extension to vCenter Server that plans, tests and runs the recovery of virtual machines, using the same replication foundations.
• Your recovery plans survive. Protection groups, recovery plans, mappings and the test failover model all continue as before.
• The interface is in transition. Broadcom describe the rebranding as an ongoing effort, and parts of the interface may still carry the older Site Recovery branding. This is cosmetic, and it is worth telling your team so nobody reports it as a fault.
• Documentation and knowledge base articles span both names. When searching, use both. A great deal of accumulated Site Recovery Manager material remains accurate and is indexed under the old name.
• Licensing moved to subscription. This is the change with real commercial consequence, and it is covered below.

The VMware Live Recovery Family

Understanding the two halves matters, because they solve different problems and a great many conversations about DR strategy conflate them.

Table 1 - The two halves of the VMware Live Recovery family.

The important point for planning is that these are complementary rather than alternatives. A traditional site recovery design protects against the site being unavailable. It does not, on its own, protect against something malicious replicating faithfully to your recovery site, which is precisely what ransomware does. Organisations that have only ever had SRM frequently have a gap here that predates the rebrand and has nothing to do with it.

Worth noting alongside this, VCF 9.1 introduced an on-premises cyber recovery clean room with network isolation and endpoint detection integration, which gives organisations a further option for isolated recovery on their own infrastructure. If data sovereignty rules out cloud-based recovery, that is the direction to investigate.

What VMware Live Site Recovery Actually Is

It is an extension to vCenter Server that delivers business continuity and disaster recovery by letting you plan, test and run the recovery of virtual machines. That definition is worth reading carefully, because the emphasis is on planning, testing and orchestration rather than on the replication itself.

This is the single most misunderstood thing about the product. VMware Live Site Recovery is primarily an orchestration engine. It discovers and manages replicated datastores and automates the migration of inventory between sites, but the data movement is performed by a replication technology underneath it, and you choose which.

• Protection groups. The unit of protection, grouping virtual machines that fail over together. Scale here has increased in the current release stream.
• Recovery plans. The orchestration: what starts, in what order, with what dependencies, what scripts run, where the pauses are.
• Inventory mappings. How resources, folders and networks at the protected site correspond to the recovery site. Getting these wrong is the most common cause of a failover that technically succeeds and operationally does not.
• Test failover. Recovery into an isolated network without disturbing production or breaking replication. This is the capability that most justifies the product, and the one most organisations under-use.
• Planned migration and reprotect. Orderly movement between sites with the ability to reverse the protection direction afterwards, which is what makes failback practical rather than theoretical.

The Three Replication Options

VMware Live Site Recovery supports array-based replication, host-based replication through vSphere Replication, Virtual Volumes replication, or a combination of these within the same environment. The choice is a design decision with real consequences and it is worth making deliberately rather than inheriting.

Table 2 - Comparing the three replication options.

Two practical notes. Storage Replication Adapters for array-based replication can be added at any time without requiring a new release of VMware Live Site Recovery, so array support is not gated on the product release cycle. And Virtual Volumes support arrived in the 9.0.3 release, so if vVols is in your design, confirm your minimum version rather than assuming.

The most common design mistake we see is choosing array-based replication because the storage team prefers it, on an estate where only a fraction of virtual machines need protecting. Datastore-level granularity means protecting the datastore, which means replicating everything on it. Host-based replication protects per virtual machine and frequently costs less in bandwidth and storage on exactly that profile. Our design and deployment guide works through that decision in detail.

What Is New in the 9.0 Release Stream

The current release stream has been steady rather than dramatic, which for a DR product is the correct kind of release.

• The maximum number of virtual machines per protection group increased to 1500 in version 9.0, which materially changes how large estates can be structured and reduces protection group sprawl.
• Support for stretched storage solutions from major storage partners arrived in 9.0 and later, with the specifics depending on the partner adapter. If you run stretched storage, check the partner position rather than the product documentation alone.
• Virtual Volumes support arrived in 9.0.3.
• An Aria Automation Orchestrator plug-in is available for 9.0, which matters if your DR invocation is wrapped in wider automation.
• The release stream has continued through 9.0.5, so evaluate and plan against the current patch level rather than the base release.

The protection group scale increase is the item with the most design consequence. Estates that split protection groups purely to stay within previous limits can often be simplified, and simpler protection group structures produce simpler recovery plans, which are easier to test and less likely to contain a stale mapping. The version-by-version comparison sets out exactly what changed between an 8.x deployment and the current stream.

Licensing and What It Means

This is where most of the real change sits. VMware Live Recovery moved to a subscription model, and organisations that held perpetual Site Recovery Manager licences have felt that at renewal rather than at rebrand.

• Both the protected and recovery sites require appropriate licensing, and vSphere and vCenter Server licensing is required at both sites as well. This is not new, but it is worth re-confirming when modelling costs.
• Subscription entitlements can span the site recovery and cyber recovery halves of the family, which is worth understanding before buying them separately.
• Model the cost against protected workloads rather than total estate. Organisations frequently discover that they have been protecting virtual machines nobody would actually recover, and a licensing review is a good moment to correct that.
• Confirm your specific entitlement with Broadcom in writing rather than inferring it, particularly where an existing agreement is being transitioned.

The commercial pressure has prompted a fair number of organisations to look at alternatives, which is a legitimate exercise. It is worth doing with the full picture, because the orchestration and testing capability that VMware Live Site Recovery provides is the part organisations most often fail to replicate when they move, and its absence does not become visible until an actual invocation.

Does Your Existing Design Still Hold?

For most organisations this is a more valuable question than anything about the rebrand. DR designs age badly because the estate changes around them and the design does not.

• Do your recovery objectives still match the business? Recovery time and recovery point objectives set five years ago frequently no longer reflect what the business would tolerate, in either direction. Some systems have become more critical, and some have become less so and are being protected expensively for no reason.
• Are your inventory mappings current? Networks, folders and resource pools change. A stale mapping produces a failover that completes and delivers virtual machines nobody can reach.
• When did you last run a real test? Test failover exists precisely so this can be answered with a date. If the answer is a shrug, that is the finding.
• Is your protection group structure a design or an accident? Many were shaped by old scale limits or by how storage happened to be laid out. The current per-group limit of 1500 virtual machines allows considerable simplification.
• Does the plan account for what recovers outside it? Identity, DNS, certificate services and management infrastructure. A recovery plan that assumes those are available at the recovery site is a plan that has not been tested honestly.
• Is ransomware in scope? Site recovery replicates faithfully, including encryption. If your only DR capability is replication-based, that is a gap regardless of which product you use.

Where to Start: A Checklist

• Current version recorded and compared against the 9.0 release stream, including patch level
• Licensing position confirmed with Broadcom in writing, covering both sites
• Replication method reviewed against the protection profile, particularly where array-based replication is protecting datastores with unprotected workloads on them
• Protection group structure reviewed against current scale limits rather than historical ones
• Inventory mappings audited for currency, especially networks
• Recovery plans reviewed for stale scripts, retired dependencies and departed people named in pauses
• Date of last successful test failover established, per plan rather than in general
• Recovery objectives revalidated with the business rather than assumed
• Dependency on infrastructure outside the plan documented: identity, DNS, certificates, management
• Ransomware recovery capability assessed separately from site recovery capability
• Runbook confirmed to be usable by whoever is on call, not only by whoever wrote it

Where DR Estates Go Wrong

Testing the plan that works. Teams test the recovery plan they are confident about and leave the complex one untested for years. The untested plan is the one that will be invoked.

Protecting everything. Expensive, slower to recover, and it dilutes attention from the systems that genuinely matter. A protection review usually pays for itself.

Array-based replication on a partially protected estate. Datastore granularity means replicating workloads you did not intend to protect, and paying for the bandwidth and capacity.

Assuming the recovery site is like the protected site. Different networks, different capacity, different security posture. The mappings encode those differences and they drift.

Treating DR as an infrastructure exercise. Application owners need to validate recovery. Infrastructure can confirm virtual machines are running, which is not the same as confirming the service works.

No ransomware position. Replication-based site recovery protects against the site being lost, not against the data being deliberately damaged. These need separate answers.

Frequently Asked Questions

Is Site Recovery Manager discontinued?

No. It was rebranded as VMware Live Site Recovery and brought under the VMware Live Recovery family alongside the former Cloud Disaster Recovery, now VMware Live Cyber Recovery. The product architecture, protection groups and recovery plans continue as before, and the rebranding is described as an ongoing effort so some interface elements may still show the previous branding.

Do our existing recovery plans still work?

Yes. Protection groups, recovery plans, inventory mappings and test failover all continue. What is worth reviewing is whether those plans are still correct for the estate as it exists today, which is a different question and usually a more productive one.

What is the difference between Live Site Recovery and Live Cyber Recovery?

Live Site Recovery is the former Site Recovery Manager, addressing site failure and planned migration through replication and orchestrated recovery plans to your own second site. Live Cyber Recovery is the former Cloud Disaster Recovery, addressing ransomware and cyber incidents through immutable snapshots and an isolated recovery environment. They are complementary rather than alternatives.

Which replication method should we use?

It depends on your storage and on what proportion of the estate needs protecting. Array-based replication suits large estates on capable matched arrays and works at datastore granularity. vSphere Replication works per virtual machine, needs no matching arrays and no adapter, and often costs less where only part of the estate is protected. Virtual Volumes replication, supported from 9.0.3, suits vVols estates wanting per-VM array replication.

How many virtual machines can a protection group hold?

Version 9.0 increased the maximum to 1500 per protection group. If your protection group structure was shaped by older limits, this is worth revisiting, since simpler structures produce simpler recovery plans and fewer stale mappings.

Does it support stretched storage?

Versions 9.0 and later support stretched storage solutions from major storage partners, with the specifics depending on the partner adapter. Check the storage partner compatibility position for your array rather than the product documentation alone.

Should we look at alternatives given the licensing change?

It is a reasonable exercise and worth doing properly. The area organisations most often underestimate when moving is orchestration and non-disruptive testing, which is the part of the product that is least visible day to day and most missed during an actual invocation. Compare on recovery outcomes rather than on replication features.

Can Consult Circle review our DR estate?

Yes. We run DR reviews covering design, replication choice, protection group and recovery plan structure, test evidence and the gap between stated and achievable recovery objectives. It is a self-contained engagement and the output is useful regardless of which platform you end up running.

Where Consult Circle Fits

Most DR estates we are asked to look at are not broken. They are out of date: designed correctly for an estate that has since changed, with recovery plans that have accumulated stale mappings and objectives nobody has revalidated with the business in years.

We review, redesign and deploy VMware Live Site Recovery through our Disaster Recovery services, and we run the tests that turn a documented capability into a demonstrated one. Where a wider platform move is also in scope, that work sits alongside our VMware Cloud Foundation services. For the governance and documentation side, see our BC/DR planning service.

Related guides in this series

• SRM vs VMware Live Site Recovery: Feature Parity, What Changed and What Is New
• Designing and Deploying VMware Live Site Recovery: Architecture, Replication and Recovery Plans
• The VMware Live Site Recovery Checklist: 68 Checks
• VMware Live Site Recovery vs Zerto vs Veeam: Comparing DR Options