Introduction
Consider a platform team preparing a VMware renewal. Procurement learns that SRM is included in the platform subscription and asks whether the separate disaster recovery expense can disappear. The infrastructure team hears that a temporary key is available. Application owners assume their recovery arrangements will continue unchanged.
Those are three different conclusions, and only the first two concern licensing.
A recovery service also depends on compatible management components, functioning replication, sufficient target capacity, usable networks, trusted administrative access, and recovery plans that still represent the applications. Replacing a license does not establish those conditions. Equally, an appliance upgrade that finishes successfully does not prove that the business service can recover.
The useful decision is therefore not simply whether to obtain the new entitlement. It is how to adopt it without creating a gap between licensed capability and demonstrated recoverability.
This article uses Broadcom’s public policy and support documentation reviewed on November 13, 2026. It addresses subscription eligibility, activation, upgrade planning, and operational acceptance. It is not an environment-specific upgrade procedure or a determination of customer contract rights. Release projections remain projections, and exact-build compatibility must be checked before execution.
TL;DR
Broadcom has moved VMware Site Recovery Manager (SRM) disaster recovery into qualifying VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF) subscription packaging, effective November 2, 2026. This can remove a separate recovery-orchestration purchase for qualifying customers, but it does not remove recovery infrastructure, compatibility, lifecycle, or testing responsibilities. It also does not mean that every VMware Live Recovery cyber recovery capability is included. [1] [2]
Existing subscribers using the interim entitlement need to plan around its May 2, 2027 expiration, not simply wait for a software announcement. The temporary key provides licensing capacity for up to 10,000 protected virtual machines, but that number is not a supported appliance-sizing target. Broadcom’s stated transition target is Protection and Recovery 9.1.3 with vCenter 9.1 or later, with a projected February through April 2027 release window rather than a committed availability date. [1]
Takeaway: treat included SRM licensing as the start of a recovery-readiness project, not evidence that disaster recovery is already covered.
Continue in the VMware by Broadcom: Architecture and Operations hub for platform planning and the Operations & Resilience hub for controlled change and recovery guidance.
Jump to a section
- Eligibility and subscription paths
- Four recovery-readiness conditions
- Interim key and download path
- Invalid-key fixes
- Convergence and upgrade paths
- Compatibility at both sites
- Plan for May 2, 2027
- Expiration and replication-only limits
- Disaster recovery and cyber recovery
- Ownership and transition planning
- Recovery acceptance
- References
Classify the Entitlement Before Changing the License
Broadcom KB 461219 sets the effective date at November 2, 2026, ends standalone SRM sales, and distinguishes the following customer paths. [1]
| Customer position | Published entitlement path | Practical implication |
|---|---|---|
| Existing active VCF or VVF subscription | SRM is included for adoption, renewal, or capacity expansion through the documented existing-customer process. | Establish whether the interim key is needed and identify the transition requirements. |
| New packaging purchased, renewed, or expanded on or after the effective date | SRM is automatically included under the updated packaging; the existing-customer bridge choices do not apply. | Confirm the actual order, entitlement record, and activation process rather than assuming the bridge workflow applies. |
| Perpetual VCF, with or without active Support and Subscription (SnS) | Not eligible under this program. | Active support does not convert a perpetual license into the qualifying subscription entitlement. |
Do not collapse that table into a statement that every VMware customer receives the same license or activation process. First identify the subscription and order covering each relevant environment. Then reconcile the entitlement record, current SRM assignment, expiration dates, and protected workload scope.
For an existing standalone SRM customer, the packaging announcement is not a substitute for reviewing the existing agreement. Do not infer that every historical SRM key expires on the interim-key deadline, or that an existing purchase automatically creates a credit, refund, or cancellation right. Those questions require review against the actual transaction.
Broadcom’s licensing agreements page identifies the applicable agreement, transaction documentation, and product-specific terms as governing sources. Keep that contractual review separate from the technical question of whether a key can be assigned successfully. [3]
My recommendation is to produce one concise entitlement record before making changes: subscription identity and term, covered environments, current recovery entitlement, proposed activation route, and an accountable commercial owner. An unresolved entitlement question should not become an appliance troubleshooting exercise.
Separate the Four Decisions Hidden Inside “SRM Is Included”
There are four independent conditions to satisfy. The following diagram is a decision model for the transition, not a product architecture or an automatic upgrade sequence.
The first condition belongs primarily to licensing and procurement. The second requires platform administration. The third spans virtualization, storage, networking, security, and integration owners. The fourth requires the application owner, because infrastructure health alone cannot establish business-service recovery.
This distinction also prevents a cost-model error. Included orchestration does not supply a recovery cluster, storage capacity, replication bandwidth, application licenses, or operational labor. Those costs belong in the decision even when the SRM line item changes.
Treat the opportunity as a chance to reassess protection coverage, not an instruction to enable every available virtual machine immediately. Expansion should follow application priority, tested capacity, and an owned recovery design.
Use the Interim Key as a Bridge, Not a New Steady State
KB 461219 specifies an interim key for 10,000 protected virtual machines, expiring May 2, 2027. It cannot be split, combined, upgraded, or downgraded, and its use is restricted to active VCF/VVF subscriptions. [1] Confirm how current license assignments will be replaced in the approved change plan; do not assume that key capacities can be pooled.
The documented download route is:
In the Broadcom Support Portal, open My Downloads, choose VMware Cloud Foundation or VMware vSphere Foundation, select the corresponding version 9 product and 9.1 or later, then open Protection and Recovery > Protection and Recovery (Key). Download the PDF containing the term-limited key. Use this key group rather than the group containing the software bits. [1]
Before assigning it, capture the current license and solution-asset state at both sites, identify the approved replacement scope, and confirm the supported recovery-software baseline. After assignment, verify the actual asset association and license status. A successful download is not activation evidence.
Licensing Capacity Is Not Recovery Capacity
The 10,000-VM figure should not become a sizing assumption. Treat it as the key’s licensing capacity, not permission to build one recovery appliance, one site pair, or one recovery plan at that scale.
Check the applicable configuration maximums and replication limits separately. Then size compute, memory, storage, and network capacity for the required failure scenario.
For example, a shared VCF recovery site should be assessed against the set of source sites that may fail together. Counting licensed VMs does not answer how much capacity must be reserved, which applications can recover concurrently, or whether testing can run without displacing production recovery capacity.
The commercial question is how many workloads may be protected under the entitlement. The architecture question is how many workloads can recover within their objectives under the failure conditions the business expects the design to survive.
Fix License Recognition Before Diagnosing Entitlement Failure
Broadcom KB 438925 documents a validation defect affecting certain recovery releases when applying keys generated on or after April 20, 2026. Older validation libraries may reject the newer license format. [4]
The published remediation branches relevant to SRM are shown below. [4]
| Installed release described in the remediation | Minimum corrected release identified by the KB |
|---|---|
| VMware Live Site Recovery/SRM 9.0.1 through 9.0.2.3 | 9.0.2.4 or later |
| VMware Live Recovery 9.0.3, 9.0.4, or 9.0.5 | 9.0.5.1 or later |
| Protection and Recovery 9.1.0.0 | 9.1.0.0100 or later |
These are license-recognition fixes, not a complete interoperability matrix or a recommendation to stop at the oldest corrected patch. Select an approved target using the current upgrade path, release guidance, and both sites’ dependencies. For starting releases not mapped by these rows, including SRM 8.x, establish the applicable path rather than extrapolating from the table.
There is an important scope conflict to handle correctly. KB 438925 includes a generic split-and-merge fallback for persistent licensing problems. The interim-key policy explicitly prohibits those operations. [1] [4]
Do not apply that generic fallback to the restricted interim key. Escalate an unresolved interim-key failure to Broadcom.
The operational lesson is straightforward: an “invalid key” error can be a software-recognition problem. It does not, by itself, establish that the customer lacks entitlement. Capture the exact error, appliance release, license type, and assignment state before choosing a remediation.
Choose the Upgrade Path from the Appliance Architecture
The recovery product names have changed across releases, and the deployment model has changed with them. Record the actual appliance layout rather than relying on the name on an old diagram or purchase order.
Separate Appliances Need a Convergence Decision
Broadcom KB 408127 describes moving separate recovery services into the combined VMware Live Recovery appliance. For the documented legacy path, direct in-place upgrading of the 9.0.2 appliances to 9.0.4 is not supported. The process uses a new combined appliance and convergence to migrate configuration. [5]
The KB identifies 9.0.2.2 or later as a source-appliance prerequisite, alongside legacy-appliance access and Enhanced vSphere Replication where applicable. That convergence minimum is not the same as the license-recognition patch requirement above. Record both requirements before selecting an intermediate release. [4] [5]
Prepare the transition at both protected and recovery sites. Preserve the configuration needed to reconstruct the service, establish the supported backup and rollback points, and verify name resolution, certificates, credentials, and network access before execution.
Convergence changes the recovery management infrastructure. The change plan therefore needs to explain how the team will respond if a real incident occurs while that infrastructure is being changed.
Already-Converged Appliances Should Not Be Converged Again
Broadcom KB 457078 addresses a different case: VMware Live Recovery 9.0.5 moving to Protection and Recovery 9.1.1. The documented path is an in-place update, not another convergence operation, because 9.0.4 and 9.0.5 are already converged appliances. The procedure includes reconfiguration and site-pair reconnection. [6]
That distinction avoids treating every older environment as a migration to a newly deployed appliance. It also avoids presenting this documented 9.1.1 example as proof of a future direct path to 9.1.3.
Confirm the final target’s published upgrade guidance when it becomes available. A documented path to one release is not evidence that every subsequent release supports the same sequence.
Rebuilding a Small Deployment Is Not a General Migration Strategy
KB 444864 describes a fresh-deployment alternative for a minimal environment, such as a single replication without existing protection groups or recovery plans. That limited scope matters. [7]
Do not generalize the teardown procedure to an estate with established recovery plans, scripts, inventory mappings, and application dependencies. Assess the cost and risk of recreating that state before selecting rebuild over migration.
The objective should be to preserve recovery intent, not simply reduce appliance count.
Validate the Dependency Chain on Both Sites
Broadcom’s Site Recovery Manager Appliance Upgrade Best Practices, KB 385248, directs administrators to verify product interoperability and upgrade paths, including checks at both production and recovery sites. Use that as the starting point for an environment-specific compatibility record, supported by an exact-build compatibility and transition plan. [8]
Connect this inventory to the recovery control-plane backup and fleet DR runbook. The record should cover vCenter and host builds, recovery appliances, replication method, storage systems and firmware, Storage Replication Adapters (SRAs), site-pair topology, and any automation or monitoring integration used to operate recovery.
Include intermediate states, not just the final combination. A supported destination does not prove that every route to it is supported.
For array-based replication, Broadcom’s combined-appliance engineering article states that SRAs and array managers must be installed and configured separately on the new appliance. Assign that work to a named owner. Do not assume that moving the recovery configuration also completes the storage integration. [9]
The consequence of skipping these checks is concrete. KB 438648 documents protection-group and recovery-plan failures with standalone SRM 9.0.2 and vCenter 9.0 or 9.1. A site pair can appear connected while storage-related operations fail. In that documented case, the management relationship is not proof of supported operation. [10]
I would require the transition plan to answer three questions before a change is approved:
- What component combinations exist during each stage?
- Which recovery operations remain available at that stage?
- What supported action restores service if the stage fails?
A list of target version numbers is not enough.
For VCF-managed components, reconcile the recovery transition with the approved platform lifecycle workflow. Do not independently change vCenter just to meet a licensing target without validating the surrounding platform dependencies.
Plan Backward from Expiration, Not Forward from a Release Announcement
KB 461219 projects VCF/VVF 9.1.3 for February through April 2027. Its stated transition target is Protection and Recovery 9.1.3 with vCenter 9.1 or later. [1]
That is forward-looking guidance, not a generally available release or a complete execution procedure.
A broad release window and a fixed license expiration create a scheduling risk. The following dates are illustrative availability scenarios, not predictions. The values are calendar-date differences to the interim-key deadline, before validation, approvals, implementation, or retesting.
| Illustrative date the usable release becomes available | Calendar days remaining to May 2, 2027 |
|---|---|
| February 1, 2027 | 90 |
| April 1, 2027 | 31 |
| April 30, 2027 | 2 |
The release is only usable for a particular deployment once the required compatibility information, media, integration support, and internal acceptance conditions are available. General availability and customer readiness are different dates.
Use a backward plan. Reserve time for final compatibility review, a representative pilot, production changes, recovery testing, remediation, and contingency. Where tasks can overlap, model the actual critical path instead of adding every estimate mechanically.
Most discovery work can begin now: entitlement classification, version inventory, recovery-plan review, capacity assessment, dependency ownership, and identification of intermediate upgrades. Perform prerequisite changes only when they have their own supported path and acceptance criteria.
Establish an escalation trigger before the last safe start date. When the final supported path is unavailable or blocked at that trigger, obtain a documented continuity decision from Broadcom and the business risk owner.
Do not budget on an automatic extension or assume that a different license can be purchased at the last minute.
Understand What Expiration Can Affect
For systems relying on the interim key, KB 461219 requires the stated appliance and vCenter transition before May 2, 2027 to maintain service continuity. Treat the expiration as an operational risk, not merely a reminder for procurement. [1]
Other Broadcom guidance explains why licensing validation belongs in recovery acceptance. KB 312725 associates missing, insufficient, or expired SRM licensing with blocked protection and recovery operations, including failover, failback, and reprotection. [11]
Do not extrapolate that into a claim that every running production VM powers off at the interim-key deadline. The documented concern is the ability to execute recovery functions.
There is also a distinct replication-only case. KB 445654 explains that a combined appliance can display an SRM evaluation license even when only standalone vSphere Replication is used. In the documented configuration, expiration of that SRM evaluation does not stop standalone replication. [12]
That exception is not reassurance for an environment that depends on SRM recovery plans. Identify which service is actually in use, which license state applies to it, and which operations have been validated.
“Replication is healthy” and “orchestrated recovery is available” must remain separate observations.
Keep Disaster Recovery and Cyber Recovery Separate
Broadcom’s November 4, 2026 portfolio announcement distinguishes native disaster recovery for VCF/VVF from VMware Live Recovery as an Advanced Service for cyber recovery. The shared recovery terminology should not erase that commercial boundary. [2]
For architecture reviews, separate the failure scenarios as well. A site outage asks whether the service can restart elsewhere within its recovery objectives. A compromise asks additional questions: which recovery point is trustworthy, how the recovery environment is isolated, who authorizes reconnection, and how compromised identities and application dependencies are handled.
An SRM entitlement should not be presented as proof that every clean-room capability, cloud recovery service, security integration, or backup requirement is included. Map each required capability to its own entitlement and design evidence.
Likewise, the fact that SRM is included in both subscriptions does not make VVF and VCF identical platforms. Validate the surrounding services that a proposed design consumes instead of applying a VCF-specific operating model to a VVF customer without checking its dependencies.
Turn the Announcement into an Owned Transition
The practical response is a bounded program with a commercial track and an engineering track. Join them at explicit acceptance points rather than allowing licensing activity to declare the technical work complete.
| Workstream | Recommended owner | Evidence needed before proceeding |
|---|---|---|
| Entitlement and continuity | Licensing or procurement owner with the account team | Applicable subscription, activation route, current expiry, and unresolved commercial questions recorded. |
| Architecture and compatibility | Recovery architect with platform and storage owners | Current and intermediate states, supported target, replication and SRA dependencies, and recovery capacity reviewed. |
| Change execution | Platform operations and change owner | Approved sequence, recoverable configuration, stop conditions, rollback boundaries, and incident coverage. |
| Recovery acceptance | Application owner with the disaster recovery team | Application-level test results, cleanup, return-path validation, and operational handoff. |
For an illustrative existing customer with active subscriptions, separate recovery appliances, and array-based replication, these tracks should run together. The licensing team establishes the entitlement route. The platform team determines whether convergence is required. Storage engineering validates the adapter and array combination. Application owners define the evidence they need after the change.
When the adapter path is unsupported, a downloaded key does not make the change ready. When the appliance updates successfully but application testing fails, the transition is not accepted. Neither case should be hidden inside a green task-completion report.
For a new deployment, use the commercial opportunity to build a small, representative recovery service first. Include a dependency-heavy application rather than only an isolated test VM. Expand protection after the design demonstrates that it can be operated and recovered, not simply after a larger license capacity appears.
Accept the Recovery Service, Not Just the Appliance
Define acceptance before the first production change. Use the production acceptance, recovery, and Day 2 ownership guide to connect infrastructure evidence with service ownership. A useful acceptance exercise should connect license state, infrastructure state, and application behavior.
First, verify the expected entitlement and assignment at every relevant endpoint. Then confirm site pairing, replication health, protection-group membership, mappings, recovery-plan steps, and any scripts or credentials that the workflow uses. Review monitoring and escalation ownership so a license or replication fault produces an actionable alert.
Next, run a representative recovery-plan test in an isolated test network. Validate application startup order, data usability, authentication, name resolution, network policy, and application-owner smoke tests. Capture the result and the limits of what the exercise actually demonstrated.
Compare measured recovery time with the recovery time objective (RTO) for returning the business service to its agreed operating state, not merely powering on a VM. Compare the recovered data point with the recovery point objective (RPO), and validate the required data consistency. Those objectives must come from the service requirement; this licensing change does not supply them.
Complete test cleanup and confirm that normal protection remains healthy. Separately validate reprotection and the return path through an approved exercise appropriate to the environment.
An isolated test does not, on its own, prove a real failover, reprotection, or failback sequence. Do not initiate disruptive production recovery simply to close a licensing task.
Finally, hand over the resulting version baseline, entitlement record, recovery procedures, remaining exceptions, and next review trigger. Preserve both successes and failures. The evidence should allow another operator to explain what changed, what was tested, and what remains unproven without reconstructing the maintenance window from memory.
Conclusion
SRM’s inclusion in VCF and VVF is a useful commercial change because it can make recovery orchestration easier to adopt within an existing platform investment. The benefit becomes operational only when the surrounding recovery service is compatible, adequately provisioned, owned, and tested.
The immediate action is to classify the entitlement path and current appliance architecture, then establish the supported transition and its acceptance evidence. Keep license-recognition fixes distinct from final entitlement adoption. Keep convergence distinct from updating an already-converged appliance. Keep disaster recovery distinct from cyber recovery.
For any environment relying on temporary licensing, make the continuity decision early enough that a late release, unsupported integration, or failed test does not force an uncontrolled change.
The question for the next architecture review is not simply, “Do we have SRM included?” It is: “What evidence shows that our recovery service will remain licensed, supported, and usable through the transition?”
External References
[1] Broadcom, “Access to VMware Site Recovery Manager for Existing VMware Cloud Foundation and VMware vSphere Foundation Subscription Customers,” Knowledge Base, Art. 461219. [Online]. Available: https://knowledge.broadcom.com/external/article/461219/access-to-vmware-site-recovery-manager-f.html. Accessed: Nov. 13, 2026.
[2] P. Shenoy, “Broadcom Updates VMware Portfolio to Protect and Accelerate Private AI Cloud Deployments,” VMware Cloud Foundation Blog, Nov. 4, 2026. [Online]. Available: https://blogs.vmware.com/cloud-foundation/2026/11/04/broadcom-vcf-portfolio-updates/. Accessed: Nov. 13, 2026.
[3] Broadcom, “Broadcom Software Offerings – Agreements and Resources,” [Online]. Available: https://www.broadcom.com/company/legal/licensing. Accessed: Nov. 13, 2026.
[4] Broadcom, “Invalid license key error when applying the SRM license key – VMware Site Recovery Manager,” Knowledge Base, Art. 438925. [Online]. Available: https://knowledge.broadcom.com/external/article/438925/purchasing-renewing-or-splitting-license.html. Accessed: Nov. 13, 2026.
[5] Broadcom, “Steps to Converge to VMware Live Recovery Appliance 9.0.4(or newer) and Common Issues During Convergence,” Knowledge Base, Art. 408127. [Online]. Available: https://knowledge.broadcom.com/external/article/408127/steps-to-converge-to-vmware-live-recover.html. Accessed: Nov. 13, 2026.
[6] Broadcom, “Unable to converge VMware Live Recovery appliance’s components,” Knowledge Base, Art. 457078. [Online]. Available: https://knowledge.broadcom.com/external/article/457078/unable-to-converge-vmware-live-recovery.html. Accessed: Nov. 13, 2026.
[7] Broadcom, “VCF Protection and Recovery 9.1: Transition from standalone SRM and VR 9.0.2,” Knowledge Base, Art. 444864. [Online]. Available: https://knowledge.broadcom.com/external/article/444864/vcf-protection-and-recovery-91-transitio.html. Accessed: Nov. 13, 2026.
[8] Broadcom, “Site Recovery Manager Appliance Upgrade Best Practices,” Knowledge Base, Art. 385248. [Online]. Available: https://knowledge.broadcom.com/external/article/385248. Accessed: Nov. 13, 2026.
[9] M. McLaughlin, “VMware Cloud Foundation Recovery Improvements with VMware Live Recovery,” VMware Cloud Foundation Blog, Jul. 1, 2025. [Online]. Available: https://blogs.vmware.com/cloud-foundation/2025/07/01/vmware-cloud-foundation-recovery-improvements-with-vmware-live-recovery/. Accessed: Nov. 13, 2026.
[10] Broadcom, “VM Protection group and Recovery plan Creation Fails with “Unexpected exception during prepare phase” or “ActAsToken” Errors.,” Knowledge Base, Art. 438648. [Online]. Available: https://knowledge.broadcom.com/external/article/438648/vm-protection-group-and-recovery-plan-c.html. Accessed: Nov. 13, 2026.
[11] Broadcom, “There are not enough licenses installed to perform the operation,” Knowledge Base, Art. 312725. [Online]. Available: https://knowledge.broadcom.com/external/article/312725. Accessed: Nov. 13, 2026.
[12] Broadcom, “Licensing Behavior for Standalone vSphere Replication After Upgrading to VMware Live Site Recovery Converged Appliance,” Knowledge Base, Art. 445654. [Online]. Available: https://knowledge.broadcom.com/external/article/445654/licensing-behavior-for-standalone-vspher.html. Accessed: Nov. 13, 2026.