Introduction
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.
Broadcom KB 461219 sets the effective date at November 2, 2026, ends standalone SRM sales, and distinguishes the following customer paths. [1]
That is forward-looking guidance, not a generally available release or a complete execution procedure.
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]
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.
TL;DR
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.
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.
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.
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]
Jump to a section
Classify the Entitlement Before Changing the License
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]
| 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. |
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.
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]
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 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?”
Separate the Four Decisions Hidden Inside “SRM Is Included”
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.
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.
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.
[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.
Check the applicable configuration maximums and replication limits separately. Then size compute, memory, storage, and network capacity for the required failure scenario.
Choose the Upgrade Path from the Appliance Architecture
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.
Separate Appliances Need a Convergence Decision
The published remediation branches relevant to SRM are shown below. [4]
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]
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.
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.
Already-Converged Appliances Should Not Be Converged Again
I would require the transition plan to answer three questions before a change is approved:
[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.
[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.
Rebuilding a Small Deployment Is Not a General Migration Strategy
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.
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]
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]
Validate the Dependency Chain on Both Sites
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.
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.
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.
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.
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.
[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.
- What component combinations exist during each stage?
- Which recovery operations remain available at that stage?
- What supported action restores service if the stage fails?
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.
Do not apply that generic fallback to the restricted interim key. Escalate an unresolved interim-key failure to Broadcom.
Plan Backward from Expiration, Not Forward from a Release Announcement
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.
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.
A list of target version numbers is not enough.
| 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 |
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.
[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.
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 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.
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.
Understand What Expiration Can Affect
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]
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]
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.
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.
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.
Takeaway: treat included SRM licensing as the start of a recovery-readiness project, not evidence that disaster recovery is already covered.
Keep Disaster Recovery and Cyber Recovery Separate
Include intermediate states, not just the final combination. A supported destination does not prove that every route to it is supported.
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.
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]
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.
Turn the Announcement into an Owned Transition
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.
| 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. |
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.
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.
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]
Accept the Recovery Service, Not Just the Appliance
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.
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.
The objective should be to preserve recovery intent, not simply reduce appliance count.
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]
“Replication is healthy” and “orchestrated recovery is available” must remain separate observations.
[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.
Do not budget on an automatic extension or assume that a different license can be purchased at the last minute.
Conclusion
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]
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.
[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.
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.
External References
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]
Stay informed
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]
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.
[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.
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.
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.
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.
[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.
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.
Those are three different conclusions, and only the first two concern licensing.
Continue in the VMware by Broadcom: Architecture and Operations hub for platform planning and the Operations & Resilience hub for controlled change and recovery guidance.
