From SRM 8.8 to VCF Protection and Recovery 9.1: How VMware Disaster Recovery Became a Platform Capability

TL;DR

The path from Site Recovery Manager 8.8 to VMware Live Recovery 9.x and then VCF Protection and Recovery 9.1 is not simply a product-renaming exercise. SRM 8.8 centered on orchestrating recovery between paired sites. VMware Live Recovery expanded the boundary to include a broader disaster- and cyber-recovery portfolio, then introduced a converged appliance model. VCF Protection and Recovery 9.1 brings those capabilities into the VCF architecture through tighter integration with vSAN protection, VCF Operations, VCF Automation, shared recovery designs, and on-premises cyber-recovery workflows.

The practical takeaway is not that the SRM recovery-plan model disappeared. It remains foundational. What changed is the surrounding operating model. Recovery can now be designed as a coordinated private-cloud service involving platform operations, storage, security, application owners, and service consumers rather than a specialized workflow owned only by the virtualization or DR team.

Introduction

An existing SRM 8.8 environment may still represent years of careful engineering. Protection groups reflect application boundaries. Inventory mappings encode recovery-site decisions. Recovery plans capture startup order, dependencies, scripts, testing procedures, and operational knowledge that would be expensive to recreate.

The modernization question is therefore not, “Was SRM good enough?” SRM was built for a clear purpose and became a dependable recovery orchestration layer for many VMware environments.

The more useful question is this:

Which recovery capabilities should remain focused on traditional site orchestration, and which should become integrated VCF protection, observability, self-service, and cyber-recovery services?

That distinction matters because the architecture around recovery has expanded. VMware customers are no longer evaluating only a protected site, a recovery site, and a recovery plan. They may also be evaluating vSAN-native snapshots, multi-source replication, centralized protection visibility, tenant-aware workflows, shared recovery infrastructure, isolated recovery environments, security-tool integration, and policy-driven service consumption.

This article uses a product and documentation baseline verified on August 2, 2026. Licensing, support, compatibility, and entitlement details remain version-sensitive and must be validated against the current Broadcom documentation, interoperability matrices, support portal, and customer agreement before implementation.

Why This Evolution Matters

Traditional disaster recovery was often implemented as a specialized system beside the production platform. The DR team protected selected workloads, maintained replication, tested recovery plans, and coordinated failover when an event occurred. Other teams participated, but the recovery product remained the center of gravity.

VCF 9.1 changes the architectural conversation. Recovery is increasingly connected to the same storage, operations, automation, identity, networking, and governance systems used to run the private cloud. That creates opportunities for better visibility and more repeatable services, but it also creates new dependencies and ownership questions.

The decision is no longer limited to upgrading a recovery appliance. It can involve redesigning the recovery operating model.

A successful modernization effort must answer several questions:

• Which existing SRM recovery plans and application sequences remain valid?
• Which replication methods should remain array-based, move to Enhanced vSphere Replication, or use vSAN protection capabilities?
• Which services are included with the VCF platform, and which require separate subscriptions or add-ons?
• Should multiple source environments converge on shared recovery infrastructure?
• Should application or tenant teams consume protection through VCF Automation?
• Is cyber recovery a separate security program, or is it being incorrectly treated as another DR test?
• Who owns protection policy, recovery readiness, clean-room validation, capacity, and failback?

These are architecture and operating-model questions, not release-note questions.

Terminology Guardrails

The naming history is confusing because several related names describe different scopes. Treating them as interchangeable creates design, licensing, support, and communication errors.

The most important distinction is between VMware Live Site Recovery and VMware Live Recovery. Live Site Recovery was the renamed SRM product. Live Recovery was the broader solution family that included traditional disaster recovery and cyber-recovery capabilities.

A second distinction is now equally important. VCF Protection and Recovery is the broader VCF-integrated family, while vSAN Protection and Recovery describes storage-centered protection capabilities within that wider architecture.

The Scope Expanded in Three Stages

The evolution is best understood as increasing scope around a retained recovery-orchestration core.

What readers should notice is that the inner recovery-plan model remains visible at every stage. The platform did not discard the orchestration concepts that made SRM useful. It placed them inside a broader protection, observability, service-delivery, and cyber-resilience context.

Stage One: SRM 8.8 as the Recovery Orchestration Layer

SRM 8.8 used a familiar two-site mental model. A protected site hosted production workloads. A recovery site provided the infrastructure and inventory required to run those workloads after a planned migration or disruptive event. Paired vCenter Server instances and recovery components coordinated the workflow.

The architecture revolved around several durable objects and processes:

• Replication: Array-based replication through vendor Storage Replication Adapters or VM-centric vSphere Replication.
• Inventory mappings: Default recovery-site resources such as networks, folders, resource pools, and datastores.
• Protection groups: Collections of protected workloads aligned to a replication and recovery boundary.
• Recovery plans: Ordered recovery workflows containing priority groups, dependencies, scripts, prompts, startup behavior, and recovery settings.
• Test recovery: Non-disruptive validation using temporary copies and isolated test networks.
• Planned migration and disaster recovery: Controlled or emergency movement of workloads to the recovery site.
• Reprotect and failback: Reversing protection after recovery and returning workloads to the original site through a planned workflow.

This model was powerful because it transformed replication into an executable recovery process. Replicated bits alone do not provide application recovery. SRM added sequencing, mappings, repeatability, testing, and operational control.

What SRM 8.8 Optimized For

SRM 8.8 was optimized for predictable recovery between known sites with known infrastructure relationships. It assumed that architects could define the source and target inventories, operators could maintain the mappings, and application recovery could be encoded into protection groups and plans.

That model remains valid for many environments, especially where array-based replication, established storage processes, and mature recovery plans already meet the required objectives.

Its limitation was not that it lacked value. Its boundary was narrower than the recovery problem organizations now need to solve. Traditional site failure and cyber compromise are not operationally equivalent. A cyber event may require older recovery points, malware validation, network isolation, security-team evidence, staged restoration, and controls that prevent reinfection. Those functions extend beyond classic failover orchestration.

Stage Two: VMware Live Recovery 9.x Expands the Boundary

The 9.x generation introduced two related but distinct changes.

First, Site Recovery Manager became VMware Live Site Recovery. That product remained the site-recovery orchestration component customers already understood.

Second, VMware introduced VMware Live Recovery as a broader offering that brought VMware Live Site Recovery together with VMware Live Cyber Recovery. The purpose was to address traditional disasters and cyber-recovery scenarios through a wider solution and management experience.

This is the point where the architecture moved beyond a rename.

From One Recovery Product to a Recovery Portfolio

The portfolio model expanded the recovery conversation from site failover to data and cyber resilience. Traditional DR remained important, but it became one service within a broader recovery strategy.

That change matters operationally. A DR plan typically assumes the replicated recovery point is usable. A cyber-recovery process must question that assumption. It may need to identify a clean candidate, power it on in an isolated environment, inspect behavior, apply security controls, stage recovery, and only then return the workload to production.

VMware Live Recovery connected those concerns under a broader product and consumption model. It did not make disaster recovery and cyber recovery identical. It provided a framework in which both could be addressed without treating them as completely unrelated technology stacks.

The Converged Appliance Becomes an Architecture Transition

The appliance transition arrived within the 9.x generation rather than at the exact moment of the original rename. By the 9.0.3 release, VMware introduced a combined VMware Live Recovery appliance that could converge previously separate VMware Live Site Recovery, vSphere Replication, and vSAN Data Protection appliances.

The combined appliance direction brought together three major service areas:

• Enhanced vSphere Replication for site-to-site VM replication
• vSAN-based snapshot and protection services
• Site-recovery automation and orchestration

This reduced the number of independently deployed service appliances for common configurations and created a more unified lifecycle model. It also connected protection groups and recovery plans more closely with vSAN data-protection objects.

However, “converged appliance” does not mean “one appliance for every topology.” Advanced configurations such as shared recovery sites can require an additional site-recovery service appliance. Array-based replication also retains its own integration requirements because Storage Replication Adapters and array managers must still be installed and configured.

Enhanced vSphere Replication Changes the Data Path

Enhanced vSphere Replication is another important part of the 9.x transition. The enhanced model uses a more scalable host-based data path and supports automated load distribution across target hosts. In the 9.0.3 convergence path, legacy vSphere Replication configurations had to be upgraded to Enhanced vSphere Replication before adopting the combined appliance.

That is a meaningful architecture change. It affects network design, firewall rules, traffic isolation, capacity planning, and troubleshooting. An organization should not treat it as a simple appliance replacement without validating the host-to-host replication path and recovery-site resources.

Stage Three: VCF Protection and Recovery 9.1 Becomes a Platform Service

VCF Protection and Recovery 9.1 is the point where the recovery stack becomes explicitly part of the VCF product architecture and documentation model. VMware Live Recovery was renamed and integrated into VMware Cloud Foundation as VCF Protection and Recovery.

The significance is not the new label. The significance is the growing connection between recovery services and the VCF operating model.

Platform-Level Visibility Through VCF Operations

Recovery readiness has traditionally been inspected through product-specific interfaces and test reports. VCF integration adds a broader operational view.

VCF Operations management packs and protection dashboards can surface information such as protected and unprotected virtual machines, local and remote protection, recovery-service health, protected capacity, vCenter coverage, and replication-related status. This helps platform teams evaluate protection as part of overall private-cloud health rather than as a separate DR console visited only during tests or incidents.

That visibility is valuable, but it must not be confused with proof of recoverability. A green dashboard does not prove that application dependencies are correct, credentials work at the recovery site, security controls are available, or the business can operate after failover. Platform visibility should make recovery testing easier to govern, not replace testing.

VCF Automation Extends Recovery to Service Consumers

Protection and Recovery 9.1 also integrates with VCF Automation for provider and multi-tenant use cases. This introduces a different consumption model. Protection can be exposed through controlled workflows rather than configured only by a centralized DR administrator.

That can improve consistency for cloud-like private-cloud services, but it also requires policy boundaries. A service consumer should not be able to select an aggressive recovery objective without an associated capacity, cost, retention, and recovery-site policy. Self-service without entitlement and quota controls can turn recovery into an unbounded infrastructure promise.

The operating model therefore needs clear separation between:

• The team requesting protection
• The team defining approved service classes
• The team operating replication and recovery infrastructure
• The application owner validating recoverability
• The security team approving cyber-recovery procedures
• The financial owner funding reserved recovery capacity

vSAN Protection Expands Beyond a Single Storage Source

VCF 9.1 extends vSAN Protection and Recovery with multi-source replication. Workloads on vSAN, VMFS, and NFS datastores can be protected to a vSAN ESA target cluster. Multiple source clusters can also converge on a centralized recovery site through a fan-in design.

This creates a practical modernization path for heterogeneous VMware estates. An organization does not need every source workload to begin on vSAN before using a vSAN-based target recovery platform.

The design still has boundaries. The source and recovery sites require their own vCenter Server and Protection and Recovery appliance. Site pairing remains part of the model. Local vSAN protection, remote replication, site recovery, and cyber recovery also have different entitlement and service requirements.

VCF 9.1 adds operational improvements around the storage-protection layer, including hierarchical snapshot retention, tag-based protection-group membership, and manual replica seeding. These features matter because they help protection policy scale with dynamic workloads, deeper retention, and constrained WAN links.

Shared Recovery Infrastructure Becomes More Practical

Multi-source replication and shared recovery-site patterns allow multiple environments to use centralized recovery infrastructure. This can reduce stranded capacity and simplify the target architecture, but it also concentrates risk.

A shared recovery site must be designed around credible concurrent-loss scenarios. Capacity sized to recover only one source site may be financially efficient, but it is not equivalent to capacity that can recover every protected site simultaneously. Architects must document the assumed disaster scope, resource overcommitment, storage ingestion rate, network contention, operational queueing, and application priority model.

Shared recovery is therefore a portfolio decision, not only a topology pattern.

Cyber Recovery Moves On-Premises

VCF 9.1, combined with VMware Advanced Cyber Compliance, supports customer-owned on-premises isolated recovery environments. This is important for organizations with sovereignty, locality, regulatory, latency, or operating-model requirements that make a cloud-based clean room undesirable.

The cyber-recovery workflow extends the familiar site-recovery process. Candidate recovery points can be placed into a validation state inside an isolated environment, inspected with supported endpoint detection and response tooling, moved into staging, recovered at the secondary site, then reprotected and failed back when the original production environment is ready.

That workflow demonstrates the core evolution. SRM-style orchestration is still present, but it now participates in a larger security and recovery process involving restore-point selection, isolation, validation, evidence, security tooling, and controlled reintegration.

Core Architecture Comparison

This comparison intentionally separates architecture from entitlement. Product integration does not mean every capability is included in every VCF subscription or licensed for every workload. Local protection, remote replication, site recovery, array integration, multi-tenancy, cloud recovery, and advanced cyber recovery can have different commercial and technical prerequisites.

What Changed Across Four Dimensions

Product Scope: From Site Failover to Broader Resilience

SRM centered on executing recovery between sites. VMware Live Recovery widened the product boundary to address disaster and cyber recovery. VCF Protection and Recovery 9.1 connects that broader scope to the private-cloud platform.

The architecture implication is that recovery requirements should no longer be captured only as RPO and RTO. They should also include retention depth, validation time, isolation requirements, security evidence, application dependency, recovery-site capacity, tenant policy, and reintegration controls.

Deployment Architecture: From Separate Services to Converged Recovery Components

SRM, vSphere Replication, and storage-protection services historically had separate deployment and lifecycle concerns. The 9.x converged appliance reduces that fragmentation for common designs.

The architecture implication is not simply fewer virtual appliances. It is a change in upgrade sequencing, network flows, service placement, failure-domain analysis, and troubleshooting responsibility. The combined appliance should be placed and protected as part of the management architecture, while advanced topologies and array integrations remain explicitly documented.

Platform Integration: From a vCenter Workflow to VCF Services

SRM already integrated deeply with vCenter, but VCF 9.1 adds a wider platform context through VCF Operations, VCF Automation, vSAN protection, and VCF-aligned recovery-site designs.

The architecture implication is that recovery becomes part of platform governance. Protection posture can be monitored centrally. Service classes can be exposed through automation. Storage protection can be connected to orchestration. Recovery sites can be designed as shared private-cloud services.

Operating Model: From DR Ownership to Cross-Functional Recovery

Traditional SRM environments were often managed by a small virtualization, storage, or business-continuity team. Modern cyber and platform recovery requires broader participation.

The architecture implication is that ownership must be assigned across the full lifecycle:

• Platform engineering defines supported recovery patterns and service classes.
• Storage teams own capacity, snapshot behavior, replication health, and target performance.
• Network and security teams own isolation, firewalling, EDR integration, and reinfection controls.
• Application owners define dependencies, startup validation, and business acceptance.
• Operations teams own monitoring, incident execution, evidence, and escalation.
• Service consumers request protection within policy.
• Financial owners fund reserved capacity, retention, licensing, and exercises.

Without this operating model, platform integration can increase ambiguity instead of reducing it.

What Did Not Change

The evolution should not be interpreted as SRM being discarded.

Several core principles remain:

• Recovery still depends on replication or recoverable snapshots.
• Application grouping still matters.
• Recovery sequencing still matters.
• Network and inventory mappings still matter.
• Non-disruptive testing still matters.
• Reprotect and failback remain part of the lifecycle.
• Recovery-site capacity still limits what can be restored.
• A successful infrastructure failover still requires application and business validation.

The durable SRM lesson is that recovery is an orchestrated process, not a storage copy. VCF Protection and Recovery expands the number of services participating in that process, but it does not remove the need for controlled recovery plans and tested application behavior.

A Practical Modernization Decision Framework

There are three reasonable starting points. They are not maturity grades, and the third option is not automatically better than the first. The correct path depends on workload requirements, existing investments, target VCF architecture, operating capability, and entitlement.

Preserve and Upgrade

This path fits environments that:

• Depend heavily on array-based replication
• Have mature recovery plans and well-tested procedures
• Need continuity before redesigning storage or service consumption
• Have recovery objectives already met by traditional site orchestration
• Are not ready to introduce tenant workflows or cyber-recovery operations

The goal is to preserve the tested recovery model while moving to a supported product and compatibility baseline. Existing mappings, custom steps, Storage Replication Adapters, recovery plans, and failback procedures should be treated as migration assets.

This path still requires current support and interoperability validation. “Preserve” does not mean remain indefinitely on SRM 8.8.

Converge and Modernize

This path fits environments that:

• Want the combined appliance model
• Need Enhanced vSphere Replication
• Want closer vSAN protection integration
• Are consolidating recovery infrastructure
• Need centralized protection visibility
• Want to reduce lifecycle fragmentation without redesigning recovery as a tenant service

The goal is to modernize the technical recovery stack while retaining the core protected-site and recovery-site operating model.

This is often the most practical intermediate state. It allows the organization to prove the new appliance, replication path, dashboards, and storage integrations before introducing broader service-consumption or cyber-recovery changes.

Redesign as a VCF Recovery Service

This path fits environments that:

• Are standardizing on VCF 9.1
• Need shared recovery infrastructure across multiple source environments
• Want provider, tenant, or application-team protection workflows
• Need vSAN-based local and remote protection services
• Require customer-owned on-premises cyber recovery
• Want protection, observability, orchestration, governance, and cost controls aligned as one platform service

The goal is not merely to deploy Protection and Recovery 9.1. It is to define a recoverability service with explicit classes, policies, owners, capacity commitments, testing requirements, and cyber-recovery controls.

The three paths can be visualized as follows:

What the reader should notice is that the paths can be sequential. An organization can preserve stable recovery, converge the technical stack, then redesign selected services. It does not need to combine every architecture and operating-model change into one high-risk migration window.

A Phased Modernization Sequence

Establish the Recovery Baseline

Inventory the deployed versions, vCenter pairs, replication methods, Storage Replication Adapters, array managers, recovery plans, protection groups, inventory mappings, IP customization, scripts, test networks, certificates, service accounts, and custom integrations.

Then capture the operational baseline:

• Last successful recovery-plan test
• Last successful reprotect and failback test
• Observed RPO and RTO
• Recovery-site capacity and contention assumptions
• Application validation owners
• Manual steps outside the recovery plan
• Known unsupported or undocumented dependencies

Do not begin by assuming that the current configuration is healthy because replication is green.

Separate Product, Topology, and Entitlement Decisions

Create three independent decision records:

• Product decision: Which supported Protection and Recovery version and appliance model is the target?
• Topology decision: Which sites, vCenters, domains, clusters, datastores, and shared recovery relationships are required?
• Entitlement decision: Which local protection, remote replication, site recovery, multitenancy, and cyber-recovery capabilities are licensed and supported?

Combining these into one statement such as “We are moving to VCF Protection and Recovery” hides the actual design choices.

Stabilize Before Convergence

Run representative recovery plans before changing the architecture. Fix stale mappings, broken scripts, expired credentials, missing test networks, insufficient recovery capacity, and undocumented manual steps first.

A migration should not become the first meaningful recovery test in years.

Converge the Recovery Services

Validate the supported upgrade sequence and interoperability matrix. Where applicable, convert legacy vSphere Replication to Enhanced vSphere Replication, validate the new network path, deploy or converge to the combined appliance, reinstall and validate Storage Replication Adapters, and retest recovery plans.

Treat each protection mechanism as its own workstream. Array replication, Enhanced vSphere Replication, local vSAN protection, and remote vSAN replication have different dependencies and failure modes.

Add VCF Platform Integrations

After the core recovery path is stable, integrate the appropriate VCF Operations dashboards and management packs. Define VCF Automation service classes only after protection policies, quotas, ownership, and chargeback or showback expectations are clear.

If a shared recovery site is introduced, validate concurrent recovery scenarios and capacity arbitration before onboarding additional source environments.

Add Cyber Recovery as a Separate Control Program

Cyber recovery should have its own threat assumptions, isolation design, security integrations, evidence requirements, restore-point validation procedure, incident roles, and return-to-production gates.

The fact that it reuses recovery plans and replication does not make it an ordinary DR workflow. Security validation and reinfection prevention are first-class requirements.

Tooling and Automation Considerations

The move toward a VCF recovery service increases the value of automation, but it also raises the cost of automating the wrong assumptions.

Use VCF Operations for Coverage and Drift Visibility

Use platform dashboards to identify unprotected workloads, failed protection groups, replication health, protected capacity, appliance health, and coverage gaps. Build operational alerts around changes that threaten recovery objectives.

Do not use dashboard status as the only test evidence. Link operational monitoring to scheduled recovery exercises and application validation results.

Use VCF Automation for Governed Service Classes

A useful self-service catalog should expose business-readable protection classes rather than raw infrastructure settings.

For example:

• Local operational recovery
• Remote disaster recovery
• Shared-site disaster recovery
• Cyber-recovery eligible

Each class should map to approved retention, RPO, target location, recovery priority, test cadence, cost owner, and capacity policy. Tenant or application-team choice should remain inside those guardrails.

Inventory Existing SRM Automation

Existing PowerCLI, API, orchestrator, ticketing, monitoring, and reporting integrations should be treated as migration dependencies. Product names, endpoints, authentication methods, object identifiers, and supported plug-in versions can change even when the conceptual recovery plan remains intact.

Revalidate automation against the target version. Do not assume that a script is safe because it still connects.

Preserve Human Decision Gates

Planned migration, disaster declaration, cyber-recovery candidate selection, failback, and return to production can carry substantial business risk. Automate evidence collection and repeatable execution, but retain explicit approval gates where the consequence warrants them.

A platform service should reduce manual error without hiding consequential decisions.

Risks, Caveats, and Operational Gotchas

A Rename Does Not Prove an Upgrade Path

SRM 8.8, Live Site Recovery 9.x, the combined Live Recovery appliance, and Protection and Recovery 9.1 are related, but the supported path depends on exact component versions, vCenter and ESX levels, replication mode, appliance state, and topology.

Use the current interoperability and upgrade documentation for the actual sequence.

Appliance Convergence Does Not Eliminate Topology Complexity

Shared recovery sites, multiple vCenters, multiple workload domains, separate service instances, and array integrations can still require additional components. Document the logical service relationship rather than counting appliances.

VCF Integration Does Not Mean Universal Entitlement

Local vSAN protection, remote replication, site recovery, provider workflows, and Advanced Cyber Compliance are not one undifferentiated feature set. Validate the subscription, add-on, per-core, storage, and support requirements for the intended design.

Enhanced Replication Changes Network Assumptions

Host-based replication paths can change firewall, routing, bandwidth, traffic-isolation, and troubleshooting requirements. Validate the source and target host networks, not only appliance connectivity.

Shared Recovery Sites Create Correlated Capacity Risk

A shared target can improve utilization, but it creates competition for compute, memory, storage, network, operator attention, and recovery sequencing. Define which simultaneous events the design can and cannot support.

Cyber Recovery Is Not a Longer Retention Policy

More snapshots do not create a clean room. Cyber recovery requires isolation, candidate validation, security tooling, evidence, staged restoration, and return-to-production controls.

Self-Service Can Overpromise Recovery

A catalog request can create a policy assignment, but it cannot create unlimited recovery-site capacity. Tie service consumption to quotas, cost, criticality, and recoverability testing.

Observability Is Not Recoverability

Protection status, replication health, and snapshot age are necessary signals. They do not prove that an application can start, authenticate, connect to dependencies, process transactions, and return to steady-state protection.

Conclusion

The progression from Site Recovery Manager 8.8 to VMware Live Recovery 9.x and VCF Protection and Recovery 9.1 is best understood as an expansion of architectural scope.

SRM established the durable recovery model: pair sites, map resources, group applications, orchestrate recovery, test non-disruptively, reprotect, and fail back. VMware Live Recovery placed that model inside a broader disaster- and cyber-recovery portfolio, then reduced deployment fragmentation through a converged appliance direction. VCF Protection and Recovery 9.1 connects recovery more directly to vSAN protection, VCF Operations, VCF Automation, shared recovery infrastructure, and on-premises cyber-recovery workflows.

The modernization decision should therefore preserve proven recovery logic while deliberately choosing which new platform capabilities to adopt. Some organizations should preserve and upgrade mature SRM designs. Others should converge the appliance and replication architecture. Organizations standardizing on VCF 9.1 may be ready to redesign recovery as a governed platform service.

The next article in this series should move from architecture to implementation: Migrating from SRM 8.8 to VCF Protection and Recovery 9.1: Dependencies, Upgrade Paths, and Design Decisions. That is where exact version sequencing, interoperability, replication conversion, appliance convergence, SRA handling, validation gates, rollback points, and topology-specific migration plans should be addressed.

External References

• Broadcom TechDocs: VMware Site Recovery Manager 8.8
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/live-recovery/site-recovery-manager/8-8.html
• Broadcom TechDocs: VMware Live Site Recovery 9.0 Release Notes
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/live-recovery/live-site-recovery/9-0/release-notes/vmware-live-site-recovery-90-release-notes.html
• Broadcom TechDocs: Converge to the VMware Live Recovery Appliance
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/live-recovery/live-recovery-appliance/9-0-3/upgrading-srm/migrate-to-the-combined-vmware-live-recovery-appliance.html
• Broadcom TechDocs: Protection and Recovery 9.1 Release Notes
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/release-notes/protection-and-recovery-91-release-notes.html
• Broadcom TechDocs: Using Protection and Recovery with VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/multi-tenant-disaster-recovery-for-vcf-automation.html
• VMware Cloud Foundation Blog: Announcing VMware Live Recovery
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2024/03/19/announcing-vmware-live-recovery-2/
• VMware Cloud Foundation Blog: VMware Cloud Foundation Recovery Improvements with VMware Live Recovery
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/07/01/vmware-cloud-foundation-recovery-improvements-with-vmware-live-recovery/
• VMware Cloud Foundation Blog: VMware vSAN Protection and Recovery Enhancements for VCF 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/14/vmware-vsan-protection-and-recovery-enhancements-for-vcf-9-1/
• VMware Cloud Foundation Blog: Continuous Compliance, Integrated Cyber Recovery and Enhanced Platform Security for VCF 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1/

The post From SRM 8.8 to VCF Protection and Recovery 9.1: How VMware Disaster Recovery Became a Platform Capability appeared first on Digital Thought Disruption.