Introduction
Platform transformation is usually planned as a sequence of discoveries, upgrades, replication jobs, test migrations, cutovers, and decommissioning activities. Recovery is often treated as a separate operational concern that will somehow continue working while those activities occur.
That assumption is dangerous.
During a VMware upgrade, hypervisor migration, or multiyear platform replacement, the environment contains more versions, more trust relationships, more temporary tooling, more replication paths, and more partially migrated applications than it does during steady-state operations. The transformation program is deliberately changing the same storage, networking, identity, management, and compute dependencies that the existing recovery plan assumes will remain stable.
Recovery coverage often becomes weakest during the exact period when migration and configuration risk are highest.
An enterprise therefore needs more than a migration plan. It needs a transformation recovery architecture that defines how workloads, data, management systems, identities, networks, and recovery evidence will be protected throughout coexistence.
TL;DR
Do not replace the source recovery chain until the destination recovery chain has been deployed, tested, measured, and accepted.
Keep source-platform backups and disaster recovery active during discovery, replication, migration, and stabilization. Treat migration replication as a transport mechanism, not automatically as disaster recovery. Validate every VMware pairing against the current Broadcom Product Interoperability Matrix, including exact patches, storage adapters, vCenter versions, ESXi versions, and replication components.
At cutover, determine whether recovery means returning to the source platform or recovering forward on the destination. That decision changes once applications begin accepting writes on the new platform.
The safest transformation uses overlapping protection:
Only after destination restores, failovers, identity dependencies, network mappings, monitoring, and operational ownership have passed acceptance testing should the original protection chain be retired.
Why Transformation Creates a Recovery Gap
A stable production platform normally has an established protection model:
Backup agents and proxies are registered.
Storage snapshots follow known schedules.
Replication relationships are monitored.
Recovery networks are mapped.
Operators know which console to use.
Application owners understand the failover process.
RTO and RPO measurements are based on repeated tests.
Support teams know which logs and vendors are involved.
Transformation disturbs that stability.
A discovery appliance may add new credentials and network paths. Replication tools may create snapshots or change tracking state. Hypervisor upgrades may alter compatibility with backup software, storage adapters, VMware Tools, virtual hardware, or recovery orchestration. A destination platform may use different VM formats, network abstractions, identity integrations, and recovery products.
The result is not simply an old platform and a new platform. It is a temporary third architecture: the coexistence environment.
That coexistence architecture deserves its own recovery design.
Migration Plans and Recovery Plans Solve Different Problems
A migration plan describes the expected path. A recovery plan describes what happens when the expected path breaks.
ConcernMigration planRecovery planPrimary objectiveMove a workload to a target stateRestore an acceptable business serviceNormal triggerScheduled wave or cutoverFailure, corruption, cyber event, or failed cutoverData movementSeed, synchronize, convert, and cut overRestore, replicate, fail over, or reconstructSuccess conditionWorkload runs on the destinationBusiness service meets recovery acceptance criteriaSource handlingUsually retained until cutoverMay remain the recovery authority for weeks or monthsDestination handlingPrepared as the targetMust be independently recoverableTestingTest migration or pilot cutoverRestore test, failover test, clean-room test, and application validationNetwork changesPlanned mappings and new addressesEmergency network activation and dependency restorationFailure responseRetry, reschedule, or roll backRecover source, recover target, or reconcile divergent dataEvidenceMigration logs and acceptance resultsRecovery reports, restore evidence, RTO, RPO, and application validation
A migration tool can successfully copy and convert a VM without providing a valid backup chain, point-in-time retention, ransomware isolation, application-consistent recovery, or orchestrated disaster recovery.
Similarly, a traditional source backup may remain technically healthy while being unable to restore directly to the new hypervisor.
Both conditions must be visible in the design.
Use Current VMware Protection and Recovery Terminology
VMware recovery terminology has changed several times, and mixed-version projects frequently contain all of the old names at once.
As of VCF 9.1, VMware Live Recovery has been renamed and integrated into VMware Cloud Foundation as VCF Protection and Recovery. Older environments and documentation may still use VMware Live Site Recovery, VMware Site Recovery Manager, SRM, vSphere Replication, or the VMware Live Recovery appliance. [1]
The Broadcom Product Interoperability Matrix now consolidates historical Site Recovery Manager and VMware Live Site Recovery entries under the Protection and Recovery product category. [2]
TermPractical interpretation during transformationVMware Site Recovery ManagerHistorical product name commonly associated with 8.x and earlier releases. SRM terminology remains common in logs, APIs, support articles, and operator language.VMware Live Site RecoveryName used by the 9.0.x site recovery orchestration releases.VMware Live RecoveryThe former recovery portfolio and, beginning with later 9.0 releases, the converged appliance containing several protection services.VCF Protection and RecoveryCurrent VCF 9.1 product family and documentation terminology.vSphere ReplicationVMware hypervisor-based, VM-centric replication technology. It remains a distinct replication service even when delivered through a converged appliance.Array-based replicationStorage-system replication integrated with recovery orchestration through a vendor-provided Storage Replication Adapter.vSAN Protection and RecoveryVCF capabilities for snapshots, replication, retention, and associated recovery workflows involving vSAN.Advanced Cyber ComplianceAdditional cyber-recovery and compliance capabilities that can extend protection into isolated recovery workflows.
Do not rename every component in a design document merely to make it look current. Record both the deployed name and the current product-family name so operators can correlate the architecture with user interfaces, logs, licenses, support cases, and compatibility matrices.
For example:
Deployed component:
VMware Live Site Recovery 9.0.5
Current matrix category:
Protection and Recovery
Target component:
VCF Protection and Recovery 9.1
The Transformation Recovery Architecture
A recovery architecture for transformation should preserve four independent control paths:
Source-platform protection.
Migration or conversion replication.
Destination-platform protection.
Cyber-resilient or independently isolated recovery.
The reader should notice that the migration path does not replace either recovery path in the following diagram.
The migration program should be unable to destroy the only usable recovery copy through one administrative mistake, one compromised credential, or one incorrect cleanup action.
Recovery Design Principles for Coexistence
Several principles should govern every phase.
Preserve the Last Known-Good Recovery Authority
At any point in the transformation, the program must be able to identify one authoritative recovery path for every workload.
That authority may be:
The source backup platform.
Source-side replication and recovery orchestration.
A destination backup created after migration.
Destination-native disaster recovery.
An independent immutable backup or cyber vault.
An application-native restore process.
“Replicating” is not an acceptable recovery classification. The architecture must identify what can be recovered, to where, from which point in time, with which dependencies, by which team.
Overlap Protection Instead of Performing a Same-Day Handoff
Do not stop source protection on the morning of cutover and assume the first target backup will succeed that evening.
The handoff should overlap:
For high-criticality workloads, retain source protection through at least one complete destination backup cycle, one verified restore, one application validation, and the agreed rollback-retention period.
Separate Recoverability from Replicability
Replication may faithfully reproduce corruption, encryption, unauthorized deletion, or application-level inconsistency. Recovery requires point-in-time choice, retention, validation, isolation, and operational procedures.
A low replication RPO does not prove that the replicated service is recoverable.
Make Recovery State Part of Migration State
A workload should not be marked simply as “migrated.” A useful state model is:
Discovered.
Source protected.
Migration ready.
Replicating.
Test recovered.
Test migrated.
Cut over.
Destination protected.
Destination restore validated.
Rollback window closed.
Source protection retired.
This exposes workloads that have moved but are not yet safely recoverable.
Treat Shared Dependencies as First-Class Recovery Objects
A VM may restore successfully while the business service remains unavailable because DNS, identity, secrets, certificates, load balancers, firewall policy, database connectivity, or storage access did not recover.
Recovery scope must follow the application dependency graph, not the VM inventory.
Phase-by-Phase Recovery Control Matrix
The following matrix can be adapted into a program control register.
Transformation phaseRecovery objectiveSource controlsDestination controlsRequired evidenceExit conditionDiscovery and assessmentAvoid reducing existing recoverabilityPreserve backup schedules, DR plans, retention, and monitoringNone required yet, but target requirements are documentedSource restore evidence, application inventory, dependency mapEvery in-scope workload has an identified current recovery methodTarget designEnsure the target can support required recovery outcomesMaintain source protectionSelect target backup, DR, cyber recovery, and management recovery designsCompatibility records, RTO and RPO mapping, capacity modelTarget recovery architecture is approvedTarget buildEstablish a recoverable target platformContinue source protectionProtect management plane, configure backup infrastructure, build recovery networksPlatform backup, configuration exports, control-plane restore procedureTarget platform can be reconstructed or restoredPilot replicationProve data transport without changing the recovery authoritySource remains authoritativePrepare temporary test protectionReplication health, snapshot impact, network mapping, test logsPilot data reaches the target without damaging source protectionPilot migrationValidate conversion and workload operationRetain source backup and rollback capabilityPerform isolated destination backup and restoreApplication test, data validation, destination restore reportPilot workload is operational and independently recoverableProduction wavesMaintain two viable recovery pathsKeep source backup and DR activeStart target protection immediately after each cutoverPer-wave backup success, restore sample, monitoring coverageEvery migrated workload has destination protectionCoexistenceControl split ownership and mixed recoveryMonitor remaining source workloadsMonitor migrated target workloadsUnified dashboard, ownership register, unresolved exception listNo workload is unowned or protected only by a temporary migration toolFinal cutoverRecover from partial or failed transitionPreserve last source restore point and rollback stateCapture target recovery point before business writes where possibleFinal synchronization evidence, validation results, decision logBusiness owner accepts target serviceStabilizationProve target recovery under normal operationsRetain source copies according to rollback policyTest destination restore, failover, and cyber controlsMeasured RTO and RPO, application signoff, support handoffDestination recovery objectives are demonstratedDecommissioningRetire obsolete protection safelyRemove jobs only after approval, retain required archivesConfirm target retention and compliance coverageDecommission checklist, legal retention decision, evidence archiveOriginal protection chain is formally retired
This matrix should be reviewed by the migration architect, backup owner, disaster recovery owner, application owner, network team, identity team, security team, and service owner.
Protect the Source During Discovery and Assessment
Discovery feels non-invasive, but it introduces operational risk.
Migration and assessment appliances often require broad inventory permissions, access to vCenter or hypervisor APIs, network connectivity to source hosts, and storage capacity for metadata or replicated data. Some tools require VMware Tools, guest credentials, snapshot operations, or change tracking.
Before discovery begins:
Verify that source backup and replication jobs are healthy.
Perform at least one representative restore from current backups.
Export recovery-plan configurations and replication mappings.
Record existing RPO violations and unresolved backup failures.
Identify workloads excluded from backup.
Document snapshot-sensitive applications and large-delta workloads.
Record RDMs, shared disks, passthrough devices, encrypted VMs, vTPMs, secure boot, and hardware-bound licenses.
Confirm that discovery permissions cannot modify or delete source workloads unless modification is explicitly required.
Capture the source platform’s version, build, certificate, plug-in, SRA, backup-agent, and storage-firmware baseline.
Create a recovery change freeze for protection systems during critical assessment windows.
Discovery should produce a recoverability inventory, not only a migration inventory.
For each workload, capture:
Recovery attributeExample questionsCurrent backupWhich product, repository, policy, and retention period protect it?Current replicationIs it protected by vSphere Replication, array replication, application replication, or another mechanism?Application consistencyIs VSS, database quiescing, log backup, or application-native protection used?Recovery targetCan it recover only to the source platform, or also to an alternate platform?Recovery dependenciesWhich domain controllers, DNS servers, certificate authorities, secrets, networks, and databases are required?Last successful testWhen was it restored or failed over, and what actually passed?Rollback limitHow long can the source remain authoritative after target cutover?Data divergence riskCan users or integrations write to both copies?
Build Destination Protection Before the First Production Wave
A new platform is not production-ready merely because it can run a migrated VM.
Before the first production migration, the destination requires:
A supported backup architecture.
Repository capacity and immutability appropriate to the risk.
Backup proxy or data-mover placement.
Encryption and key-management design.
Application-aware processing where required.
Platform and management-plane backups.
Restore networks or isolated recovery networks.
A destination disaster recovery strategy.
Monitoring for backup, replication, and restore failures.
Operator access and break-glass procedures.
Retention, legal hold, and data-sovereignty decisions.
Recovery runbooks and support ownership.
A migrated workload should enter target protection during the same controlled change window whenever practical. Waiting several days creates a protection gap in which the source may no longer contain current data and the target may not yet have a usable recovery point.
Mixed-Version Compatibility Must Be Proven, Not Assumed
Mixed-version VMware recovery can be supported, but compatibility is not a general promise that any N-minus-one combination will work.
As of July 23, 2026, Broadcom exposes current and historical recovery products under the Protection and Recovery category in its Product Interoperability Matrix. The matrix contains distinct compatibility relationships for Protection and Recovery 9.1, VMware Live Site Recovery 9.0.x, older Site Recovery Manager releases, vCenter versions, vSphere Replication versions, and related products. [2], [3]
The matrix currently shows Protection and Recovery 9.1 compatibility across selected vCenter 9.1, 9.0, and 8.0 Update 3 releases. It does not mean every older VMware Live Site Recovery patch is compatible with every newer vCenter patch.
Treat compatibility as a tuple:
Protected-site vCenter build
+ Protected-site ESXi build
+ Recovery-site vCenter build
+ Recovery-site ESXi build
+ Protection and Recovery version
+ vSphere Replication version
+ Storage Replication Adapter version
+ Array firmware and replication software
+ Backup product and plug-in versions
+ VMware Tools and guest support
A matrix entry at the product-family level is not enough when the change involves patches, add-on appliances, storage adapters, or management packs.
Build a Compatibility Evidence Record
For each migration wave or upgrade stage, record:
FieldRequired evidenceProtected-site platformExact vCenter and ESXi versions and buildsRecovery-site platformExact vCenter and ESXi versions and buildsRecovery orchestrationExact SRM, VMware Live Site Recovery, or Protection and Recovery releaseHypervisor replicationExact vSphere Replication and add-on server buildsStorage replicationArray model, firmware, replication software, and SRA versionBackup integrationBackup server, proxy, transport, agent, and plug-in compatibilityUpgrade pathDirect, stepped, or appliance-convergence pathValidation dateDate the vendor matrices were checkedEvidence ownerPerson accountable for rechecking before executionChange triggerNew patch, firmware, certificate, target build, or storage change
The Broadcom community discussion supplied with this assignment illustrates that specific mixed releases have been supported, including pairings where one site used an older ESXi and SRM family and the other used a newer release. That example is useful context, but it is not a reusable compatibility rule. [17]
Upgrade Ordering Is Part of Recovery Architecture
Upgrade sequencing should preserve at least one working recovery path throughout the change.
Before upgrading:
Validate both protected and recovery sites against the current matrix.
Confirm the supported upgrade path and any required intermediate releases.
Export recovery and replication configurations.
Back up the recovery appliances using a supported method.
Record appliance FQDNs, IP addresses, certificates, site pairings, thumbprints, service accounts, and plug-in registrations.
Resolve existing replication errors and invalid protection groups.
Verify that recovery plans are in a valid state.
Test a representative recovery before changing components.
Confirm rollback procedures for each appliance and platform component.
Broadcom’s current upgrade guidance emphasizes checking vCenter, ESXi, vSphere Replication, and recovery-product interoperability at both sites before proceeding. It also distinguishes direct updates from stepped upgrades. [6]
A practical ordering model is:
Do not upgrade vCenter, ESXi, replication, storage firmware, SRA, backup software, and the recovery appliance in the same undifferentiated window. If the recovery test fails afterward, the evidence will not identify which change caused the failure.
Protect Against Certificate and Trust Breakage
Recovery orchestration depends on more than network reachability. It relies on vCenter registrations, Lookup Service records, solution users, SSO tokens, certificates, thumbprints, and service identities.
A vCenter upgrade or certificate replacement can leave a recovery appliance powered on but unable to pair, display its plug-in, synchronize inventory, or execute recovery plans.
Certificate validation should therefore include:
FQDN and Platform Services Controller naming consistency.
Certificate expiration and chain validation.
vCenter Lookup Service registration.
Solution-user health.
Site-pair authentication.
Recovery appliance trust stores.
Direct recovery-appliance connectivity to ESXi where required.
DNS forward and reverse resolution.
Time synchronization across both sites.
Choose Replication According to the Recovery Job
Different replication technologies solve different problems.
Replication methodBest fitPrimary strengthsTransformation limitationArray-based replicationLow-RPO VMware-to-VMware recovery using supported storage platformsStorage consistency groups, efficient data movement, array-native capabilitiesDepends on array, firmware, SRA, datastore, and recovery-product compatibility; normally does not convert workloads to another hypervisorvSphere ReplicationVM-centric VMware recovery across heterogeneous storageStorage-independent at the VM level, configurable RPO, orchestration integrationRemains a vSphere technology and is not a general cross-hypervisor conversion engineMigration-tool replicationMoving and converting workloads to Azure Local, AHV, cloud, Hyper-V, or another targetDiscovery, seeding, delta synchronization, network mapping, conversion, planned cutoverOften lacks long-term retention, point-in-time recovery depth, cyber isolation, and established DR orchestrationBackup-based migrationLow-change or difficult workloads, archive migration, controlled restoreIndependent recovery copy, retention, portability where supportedLonger cutover and restore times; application reconfiguration may be requiredApplication replicationDatabases, messaging, file services, and stateful applicationsApplication-aware consistency and controlled role transitionProtects the application but not necessarily the VM, platform configuration, or shared dependenciesStorage or file synchronizationLarge datasets and content repositoriesEfficient movement of data independently of computeDoes not automatically preserve application state, VM configuration, identity, or transaction order
Array-Based Replication Requires Two Compatibility Decisions
Array-based recovery requires validation of both VMware orchestration compatibility and storage-vendor compatibility.
VMware recovery orchestration integrates with third-party array replication through vendor-provided SRAs. Broadcom stopped certifying new SRAs in August 2025, while array-based replication remains supported and storage partners continue to develop and distribute their adapters. [4], [5]
This shifts more validation responsibility to the customer and storage vendor.
Before relying on array replication during transformation, verify:
Current SRA support from the storage vendor.
Exact compatibility with the installed recovery release.
Supported array firmware and replication software.
Datastore and protocol support.
Consistency-group behavior.
Snapshot and failover semantics.
Test-recovery behavior.
Reprotect and failback behavior.
Support ownership when Broadcom and the storage vendor are both involved.
vSphere Replication Remains a VMware Recovery Mechanism
vSphere Replication provides VM-centric, hypervisor-based replication with configurable RPOs. Broadcom documents an RPO selection range from one minute to 24 hours for current entitled configurations. [4]
It is useful when:
Source and recovery storage differ.
VM-level policy is preferable to datastore-level protection.
Individual workloads require separate RPOs.
Array replication is unavailable.
vSAN or mixed storage is involved.
It should not be treated as a cross-hypervisor migration mechanism. A VMware-to-Azure Local or VMware-to-AHV move still requires a migration or conversion workflow.
Test Recovery and Test Migration Are Different Controls
A test recovery asks:
Can the protected application be recovered from its recovery copy without disrupting production?
A test migration asks:
Can the source workload be converted, configured, and operated correctly on the destination platform?
Both tests are required.
VMware Test Recovery
VCF Protection and Recovery and earlier VMware Live Site Recovery releases support nondisruptive recovery-plan testing. VMware can create isolated test networks or map recovered VMs to designated test networks. [7]
A useful test recovery validates:
Replica accessibility.
VM registration.
Boot ordering.
VMware Tools readiness.
IP customization.
Network mapping.
Application dependencies.
Database recovery.
Authentication.
Monitoring.
Cleanup.
The automatically created isolated network protects production from duplicate IPs, but it can also hide dependencies on DNS, identity, load balancers, external APIs, and other subnets. A meaningful test environment may require controlled routing, test DNS, synthetic identity services, or explicitly mapped test networks.
Test Migration
A test migration validates destination behavior:
Virtual hardware conversion.
Boot mode.
Driver replacement.
Guest-agent health.
Network-adapter changes.
Static IP handling.
Licensing tied to hardware attributes.
Time synchronization.
Application performance.
Monitoring and security agents.
Backup compatibility.
Automation and operational tooling.
Microsoft’s current VMware-to-Azure Local documentation describes discovery, replication, and planned migration. A Microsoft-hosted community answer dated March 12, 2026 states that Azure Migrate does not currently provide the same built-in Test Migrate button for Azure Local that is available for Azure IaaS migrations. It recommends using a nonproduction target, a dedicated test partition, or representative test workloads. [14]
Because that limitation is documented in a community answer rather than the core product documentation, recheck the current portal and release notes immediately before designing the test process.
Use Separate Acceptance Gates
Do not let a successful test migration replace a recovery test.
A migrated VM can boot and still be impossible to restore. A recovered VM can boot on VMware and still fail after conversion to the destination platform.
Maintain Application-Consistent Recovery
Crash-consistent recovery returns storage to a point in time that resembles sudden power loss. Application-consistent recovery coordinates the application, guest operating system, or transaction engine so that recovery produces a known-valid state.
The required level depends on the workload.
Workload typeMinimum validationStateless web tierConfiguration, secrets, image version, load-balancer registration, and dependent API accessWindows applicationVSS behavior, service ordering, certificate access, and domain authenticationSQL databaseDatabase consistency checks, transaction-log recovery, listener or connection-string validationLinux databaseDatabase-native backup or quiescing, journal recovery, service dependenciesFile serviceFile-system consistency, permissions, locks, namespace, and client accessDirectory serviceReplication health, role ownership, time, DNS, and authoritative restore considerationsClustered applicationQuorum, shared storage, fencing, node identity, and supported recovery orderMessage queueDurable-message state, broker identity, clustering, and producer or consumer replay behavior
Broadcom distinguishes disaster failover consistency from planned migration behavior. For disaster failover, consistency depends on the underlying replication method. vSphere Replication supports VSS-based application consistency for supported Windows environments, while planned migration gracefully shuts down VMs and completes the final synchronization before recovery. [4]
That still does not remove the need for application validation.
A database team should confirm that transactions are present and consistent. An identity team should confirm replication and role health. An application owner should execute a functional transaction, not merely verify that a service process is running.
Network Mapping Is a Recovery Dependency
Networking is often where a technically successful cutover becomes a business outage.
Recovery planning must distinguish:
Production network mappings.
Test-recovery network mappings.
Migration destination mappings.
Temporary coexistence networks.
Rollback mappings.
Cyber-recovery isolation networks.
Decide Whether Addresses Move or Change
There are three common patterns.
Stretch or preserve addressing
The workload retains its IP address at the destination. This can simplify application behavior but increases dependence on routing, layer-2 extension, duplicate-IP prevention, and deterministic traffic steering.
Readdress at the destination
The destination receives a new subnet and IP address. This reduces network extension but requires DNS, certificates, firewall policies, allowlists, monitoring, load balancers, and application configuration to change.
Use an abstraction layer
Load balancers, global traffic managers, proxies, service discovery, or application gateways hide the workload’s current address from consumers.
The abstraction model usually provides the cleanest rollback, but only when it has been implemented before the migration.
Test IP Customization, Not Just Its Configuration
VMware recovery orchestration can apply protected-site and recovery-site IP customizations and network mapping rules. [8]
The presence of a configured rule does not prove that the guest will accept it. Validation should include:
VMware Tools or destination guest-agent readiness.
Supported guest operating system.
Multi-NIC behavior.
Network interface naming.
Static routes.
DNS server order.
Default gateway.
MTU.
Firewall profile.
Certificate hostname bindings.
Application configuration containing literal IP addresses.
The recovery report should show whether customization succeeded, failed, or was skipped.
Prevent Duplicate Address Activation
During test, cutover, and rollback:
Ensure the source and target cannot become active on the same production address unintentionally.
Use explicit isolation or firewall controls.
Assign authority for enabling destination networks.
Record which team can advertise routes or update load balancer pools.
Validate stale ARP, neighbor, and MAC-table behavior.
Predefine rollback route changes.
Confirm that monitoring does not auto-remediate or restart the wrong copy.
Azure Local migrations also require careful static-address planning. Microsoft documents known migration failures when a requested static address is already assigned. [11]
DNS, Identity, and Certificates Determine Whether Recovery Works
Infrastructure teams frequently validate that a VM responds to ping while the application still fails because its trust dependencies did not move.
DNS
Plan for:
Record ownership.
TTL reduction before cutover.
Forward and reverse records.
Split-brain DNS.
Service records.
Load-balancer names.
Stale resolver caches.
Rollback updates.
Replication between DNS sites.
DNS availability inside recovery and test networks.
Do not lower TTLs only for the application’s public record. Internal database, directory, API, storage, and management names may also change.
Identity
Determine whether recovery depends on:
Active Directory domain controllers.
Microsoft Entra connectivity.
LDAP.
Kerberos.
Managed identities.
Service accounts.
Local break-glass accounts.
Privileged access systems.
Secrets managers.
Multifactor authentication services.
Do not migrate all domain controllers, DNS servers, or privileged-access systems in one wave. Maintain authentication capability on both sides while coexistence continues.
Certificates
Identify:
Certificates bound to source FQDNs or IP addresses.
Private certificate authority availability.
Certificate revocation and status endpoints.
Trust stores on the new platform.
vCenter and recovery-appliance certificates.
Application certificates with subject alternative names.
Hardware security modules and key vault dependencies.
Certificates embedded in automation or monitoring integrations.
A platform can recover every disk and still remain unusable because the private key, certificate chain, or issuing authority is unavailable.
Recover the Management Infrastructure
Workload recovery depends on management infrastructure that is often excluded from workload protection.
For VMware environments, this may include:
VCF Installer or SDDC Manager.
vCenter Server.
NSX Managers and Edge configuration.
VCF Operations.
Protection and Recovery appliances.
vSphere Replication services.
Backup servers and proxies.
Storage-management systems.
Hardware-management controllers.
DNS, NTP, identity, and certificate services.
For Azure Local, it may include:
Azure Local cluster configuration.
Azure Arc Resource Bridge.
Custom locations and resource providers.
Azure Migrate source and target appliances.
Failover cluster configuration.
Network ATC and software-defined networking state.
Azure subscription, resource group, Key Vault, and role assignments.
For Nutanix, it may include:
Prism Central.
Prism Element access.
Nutanix Move.
Protection policies.
Recovery plans.
Network and category configuration.
Identity and certificate integrations.
Management recovery should answer:
Which systems must be available before workloads can be recovered?
Can the recovery tool operate when the primary management plane is unavailable?
Are configurations exported outside the platform?
Are appliance backups stored independently?
Are DNS and certificates available at the recovery site?
Are break-glass credentials stored offline?
Can operators access the recovery site without the primary identity path?
Are runbooks available when documentation systems are offline?
Broadcom’s current VCF 9.1 cyber-recovery guidance explicitly addresses management-plane isolation, reinforcing that management infrastructure must be protected from the same compromise affecting production. [19]
Design Rollback for Partial Cutovers
Rollback is easy only before the target accepts writes.
Once users, applications, scheduled jobs, integrations, or message producers begin changing destination data, returning to the source may discard or duplicate business transactions.
The cutover runbook must define a point of data authority.
Rollback Before Destination Writes
If the destination has not accepted business writes:
Power down or isolate the destination.
Restore source routes, DNS, load balancer pools, and firewall rules.
Resume source application services.
Re-enable source jobs.
Confirm replication and backup state.
Record failed validation evidence.
Correct the target before retrying.
Rollback After Destination Writes
If the target has accepted writes, a simple power-on of the source may create data loss or split-brain operation.
Options include:
Reverse replication.
Database log shipping or transaction replay.
Application-level reconciliation.
Message replay.
Export and import of changed records.
Forward recovery on the destination.
Restore of the destination from a clean point followed by transaction recovery.
The application owner and data owner must approve the procedure. Infrastructure teams should not make an unreviewed decision to discard destination writes.
Define Rollback Expiration
A rollback window should have a defined duration and closure criterion.
It should not remain open indefinitely because keeping source copies available may:
Consume licensing.
Retain vulnerable software.
Create duplicate identities.
Increase attack surface.
Cause accidental startup.
Extend operational ambiguity.
Preserve stale data beyond approved retention.
Delay decommissioning and cost removal.
VMware to VMware Transformation Considerations
A VMware transformation may involve:
vCenter or ESXi upgrades.
VCF deployment or workload-domain replacement.
Storage migration.
NSX redesign.
New Protection and Recovery appliances.
Convergence from separate VMware Live Site Recovery and vSphere Replication appliances.
Movement from older SRM releases.
Changes from array-based replication to vSphere-based replication.
Changes from VMFS or NFS to vSAN.
Parallel old and new recovery sites.
The recovery architecture should avoid a simultaneous change to every layer.
A safer sequence is:
Validate current recovery.
Establish version-compatible recovery orchestration.
Upgrade or build the destination management plane.
Validate site pairing and replication.
Test recovery with representative workloads.
Move migration waves.
Establish destination protection.
Retire obsolete replication only after recovery acceptance.
The latest matrix must be checked immediately before each change window. Broadcom’s consolidated naming means teams searching only for “SRM” or “VMware Live Site Recovery” may overlook the current Protection and Recovery entries. [2]
VMware-to-Azure Local Considerations
Microsoft made Azure Migrate-based VMware VM migration to Azure Local generally available in July 2026. The solution applies to supported Azure Local releases beginning with the documented 2503 baseline and uses source and target appliances registered with an Azure Migrate project. The migration data path remains local, while Azure services provide orchestration and metadata functions. [9], [10]
That architecture creates several recovery implications.
Azure Migrate Is Not the Destination Recovery Design
Azure Migrate discovers, replicates, and migrates the workload. It does not remove the need to configure destination backup and disaster recovery.
After cutover, determine whether the Azure Local workload will use:
Azure Site Recovery to Azure.
Hyper-V Replica to another supported site.
A supported enterprise backup product.
Application-native replication.
Azure Backup or another approved data-protection method.
An independent cyber-recovery copy.
Microsoft documents Azure Site Recovery for protecting supported Azure Local VMs to Azure, including replication, test failover, failover, reprotection, and failback workflows. [13]
The current Microsoft guidance distinguishes between deployment approaches and maturity levels. Validate whether the Azure Local extension-based workflow is generally available for the intended production configuration or whether manual Hyper-V-to-Azure protection remains required.
Complete the Migration Workflow
Microsoft’s migration procedure warns that migration must be completed after target validation to avoid unexpected behavior. [12]
Do not leave production VMs indefinitely in a temporary migration state. The runbook should include:
Target validation.
Migration completion.
Source handling.
Destination backup enrollment.
Azure Arc guest-management validation.
Monitoring onboarding.
Security-agent validation.
Protection verification.
Recovery test scheduling.
Test Without a Native Test-Migrate Button
Where Azure Local lacks a nondisruptive test-migration function, use:
A representative cloned workload.
A nonproduction application instance.
A dedicated test cluster.
A segmented test network.
A planned pilot migration that can be discarded.
Application-level data masking where production data is involved.
Do not use an unisolated duplicate domain controller, database node, DHCP server, or licensed application as a casual migration test.
Account for Hardware-Bound Licensing
Virtual hardware identifiers may change when a workload moves from VMware to Azure Local or from Azure Local to Azure VMs.
Applications tied to a MAC address, BIOS UUID, hardware GUID, TPM, dongle, or system fingerprint may require vendor rehosting. A June 2026 Microsoft-hosted community discussion specifically warns that Azure does not provide a general mechanism to preserve all source hardware identifiers when moving Azure Local workloads to Azure VMs. [18]
Treat licensing validation as a prerequisite, not a post-cutover troubleshooting item.
VMware to Nutanix AHV Considerations
Nutanix Move 6.2 provides migration planning, readiness checks, data seeding, synchronization, network mapping, monitoring, and cutover workflows for supported source and target combinations. [15]
The recovery model should still separate Move from Nutanix disaster recovery.
During Migration
Maintain:
Source VMware backup.
Source VMware disaster recovery where required.
Nutanix Move appliance protection and configuration records.
Network mapping evidence.
Readiness-check output.
Source snapshot monitoring.
Cutover and cleanup procedures.
A source rollback plan.
Do not assume that a seeded AHV copy is equivalent to a tested recovery point.
After Cutover
Enroll the workload in destination-native protection:
Nutanix protection policies.
Recovery plans.
Asynchronous, NearSync, or synchronous protection where supported and justified.
Enterprise backup.
Application-native protection.
Independent immutable retention.
Nutanix disaster recovery uses protection policies and recovery plans to orchestrate protected entities between supported availability zones and recovery locations. [16]
The first production wave should not close until a migrated workload has been restored from the destination backup or exercised through the intended Nutanix recovery workflow.
Other Destination Platforms
The same model applies to Hyper-V, public-cloud IaaS, OpenShift Virtualization, KVM-based platforms, and managed VMware destinations.
For every destination, ask:
Is the migration replica recoverable independently?
Which tool owns destination backup?
Can the source backup restore directly to the target?
Which guest drivers and agents change?
How are static addresses and network security translated?
Does the target support the source VM’s boot mode, encryption, virtual hardware, shared disks, or passthrough devices?
How is management infrastructure protected?
How is disaster recovery orchestrated?
How is failback performed?
Which recovery functions are preview, limited, or platform-specific?
Can recovery be tested without affecting production?
The destination product name changes. The control model does not.
RTO and RPO Must Be Recalculated During Coexistence
Steady-state recovery objectives may not remain achievable during transformation.
RPO Changes
RPO may temporarily worsen because:
Initial seeding takes days.
Migration replication has a different schedule from DR replication.
Source backups are paused during conversion.
Target backups begin only after cutover.
Application quiescing is unavailable on one platform.
Large data changes create backlog.
Network bandwidth is shared with migration traffic.
Recovery copies exist in different products with different clocks and retention.
RTO Changes
RTO may increase because:
Operators must identify which platform is authoritative.
Recovery requires conversion.
Network mappings are temporary.
Destination capacity is reserved for migration rather than recovery.
Recovery teams must use unfamiliar tools.
Management planes depend on both old and new identity systems.
Support cases cross multiple vendors.
The application spans both platforms.
Use Phase-Specific Objectives
PhaseRPO interpretationRTO interpretationBefore replicationExisting source RPOExisting source recovery procedureInitial seedSource backup remains authoritativeSource recovery remains primaryContinuous synchronizationMigration lag is measured separately from recovery RPOTarget startup is not yet an accepted RTOPilot cutoverSource rollback point plus pilot target stateIncludes conversion and validation timeProduction coexistenceRPO differs by workload locationRecovery tool and owner depend on workload statePost-cutover before target backupPotentially highest riskMay require rollback or forward recoveryDestination protectedTarget-native RPOTarget-native recovery workflowSource retiredTarget and cyber-recovery objectives onlySource rollback no longer available
Do not publish one enterprise RPO for the whole transformation. Publish objectives by application, wave, platform state, and recovery method.
Use Dual-Platform Monitoring
During coexistence, monitoring must answer five questions:
Where is the authoritative workload running?
Which recovery policy currently protects it?
Is replication or backup meeting its objective?
Can the copy be recovered?
Who owns the next action?
Useful signals include:
Source Platform
Backup success and age.
Replication status.
RPO violations.
Snapshot age.
Recovery-plan state.
SRA or vSphere Replication health.
Source capacity and datastore latency.
Pending source decommission tasks.
Migration Layer
Initial-seed progress.
Delta synchronization lag.
Snapshot failures.
Conversion failures.
Appliance health.
Network throughput.
Cutover readiness.
Cleanup status.
Destination Platform
Backup enrollment.
Backup success and immutability.
Restore-test status.
Destination DR replication.
Platform capacity.
Guest-agent status.
Monitoring and security-agent health.
Recovery-plan membership.
Application Layer
Transaction health.
Data replication.
Queue depth.
Authentication.
Synthetic transactions.
Certificate health.
Dependency reachability.
Business-level reconciliation.
Program Controls
Workload recovery state.
Open exceptions.
Rollback deadline.
Evidence completeness.
Recovery owner.
Decommission approval.
A green migration dashboard and a red recovery dashboard should produce a red program status.
Collect Evidence as the Transformation Proceeds
Recovery confidence should be based on retained evidence, not workshop memory.
For each wave, collect:
Source backup reports.
Source restore-test evidence.
Replication health before cutover.
Migration-tool readiness reports.
Compatibility-matrix screenshots or exported records.
Exact product and build inventory.
Network and IP mappings.
DNS change records.
Certificate inventory.
Final synchronization time.
Source shutdown time.
Destination startup time.
Application validation results.
Data-reconciliation results.
Destination backup enrollment.
Destination backup success.
Destination restore-test evidence.
RTO and RPO measurements.
Rollback decision and expiration.
Source cleanup approval.
Support cases and known deviations.
Evidence should be stored outside the platform being transformed and retained according to audit, regulatory, and operational requirements.
Cyber Recovery Must Remain Independent
A platform migration can unintentionally weaken cyber recovery.
Common mistakes include:
Placing source and target backups in the same administrative domain.
Reusing privileged migration credentials for backup administration.
Allowing migration appliances to reach immutable repositories.
Disabling immutability during repository movement.
Copying already compromised data into the destination.
Removing source retention before target malware scanning is established.
Connecting an isolated recovery site to production for convenience.
Migrating identity and recovery administration simultaneously.
Treating replicated encrypted data as a clean recovery copy.
The transformation design should preserve:
Immutable or protected retention.
Separate administrative credentials.
Multifactor authentication.
Delayed deletion.
Offline configuration exports.
Isolated recovery networks.
Clean-room procedures.
Malware and EDR validation.
Known-clean recovery-point selection.
Independent evidence.
Recovery communications outside the primary environment.
Cyber recovery may require restoring forward onto the target platform rather than rolling back to an older but compromised source environment.
Decommission the Original Protection Chain Deliberately
The old recovery chain should be retired only after the destination has passed an explicit acceptance gate.
Minimum Acceptance Criteria
Before removing source protection, confirm:
All workloads in the wave are running on the destination.
No approved rollback scenario still depends on the source.
Destination backups meet the retention policy.
At least one representative restore has succeeded.
Critical applications have completed application-level recovery validation.
Destination DR replication is healthy where required.
Network recovery mappings are documented.
Identity and certificate dependencies are recoverable.
Management-plane recovery is documented.
Monitoring and alert ownership are active.
Cyber-recovery requirements are met.
Legal and regulatory retention decisions are recorded.
Source data disposal is authorized.
Support ownership has transferred.
Evidence is archived.
Decommission in Layers
A safe sequence is:
Freeze new source protection-group membership.
Confirm no active workloads depend on the source recovery plan.
Export configurations and recovery histories.
Retain required backup sets.
Remove source replication relationships.
Clean migration snapshots and temporary artifacts.
Revoke migration credentials.
Remove temporary firewall rules.
Retire source backup jobs.
Remove obsolete repositories only after retention expires.
Decommission recovery appliances and plug-ins.
Remove stale DNS, certificates, service accounts, routes, and monitoring objects.
Update the configuration management database.
Close the architecture decision and evidence record.
Do not delete the source VM, source backup, source replication, migration plan, and rollback evidence in one cleanup action.
Practical Recovery Readiness Questions
Before approving the next migration wave, ask:
Can the source workload still be restored?
Can its recovery dependencies be restored?
Is the migration copy isolated from production until approved?
Is the exact mixed-version combination supported?
Has the compatibility evidence been checked recently?
Is the storage replication adapter supported by its vendor?
Has test recovery succeeded?
Has test migration succeeded?
Is application consistency understood?
Is the destination already protected?
Has a destination restore been demonstrated?
Are DNS, identity, and certificate changes reversible?
Is the point of data authority defined?
Is rollback possible after destination writes?
Are source and target recovery signals visible together?
Are cyber-recovery copies independently protected?
Is the management plane recoverable?
Is evidence stored outside the transformed platform?
Are RTO and RPO stated for this phase?
Is the original protection chain still required?
Any unanswered question is a recovery exception that must be owned, dated, and approved.
Conclusion
Platform transformation creates a period in which infrastructure becomes more fragmented at the same time that operational risk increases. Treating recovery as an unchanged background service during that period leaves the enterprise exposed to failed upgrades, incompatible replication components, broken trust relationships, partial cutovers, data divergence, and cyber events.
The safest architecture preserves overlapping recovery controls. Source-platform backup and disaster recovery remain active while migration replication moves the workload. Destination protection begins before or immediately after cutover. Independent cyber recovery remains separated from both operational environments.
Current VMware terminology and compatibility matter. In VCF 9.1, VMware Live Recovery is now VCF Protection and Recovery, and historical SRM and VMware Live Site Recovery entries are consolidated under the Protection and Recovery category in Broadcom’s interoperability tooling. Compatibility must still be validated against exact product releases, builds, replication components, storage adapters, and both sites.
The transformation is not complete when the last VM powers on at the destination. It is complete when the destination can recover the application, its data, its management plane, its identity, its network dependencies, and its certificates within accepted objectives, and when the evidence is strong enough to retire the original protection chain without guesswork.
External References
[1] Broadcom: Protection and Recovery 9.1 Release NotesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/release-notes/protection-and-recovery-91-release-notes.html
[2] Broadcom: Protection and Recovery Category for SRM and VLSR Compatibility in Interoperability MatrixCanonical URL: https://knowledge.broadcom.com/external/article/447296/protection-and-recovery-category-for-srm.html
[3] Broadcom: Product Interoperability MatrixCanonical URL: https://interopmatrix.broadcom.com/Interoperability
[4] VMware by Broadcom: VMware Live Recovery Frequently Asked QuestionsCanonical URL: https://www.vmware.com/docs/vmware-live-recovery-faq
[5] Broadcom: VMware Live Site Recovery Storage Replication Adapter Compatibility GuideCanonical URL: https://compatibilityguide.broadcom.com/search?program=vlsrsra
[6] Broadcom: Site Recovery Manager Appliance Upgrade Best PracticesCanonical URL: https://knowledge.broadcom.com/external/article/385248/site-recovery-manager-appliance-upgrade.html
[7] Broadcom: Test Networks and Data Center NetworksCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/live-recovery/live-site-recovery/9-0/how-do-i-protect-my-environment/creating-testing-and-running-recovery-plans/testing-a-recovery-plan/test-networks-and-datacenter-networks.html
[8] Broadcom: Customizing IP Properties for Virtual MachinesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/live-recovery/live-site-recovery/9-0/how-do-i-protect-my-environment/customizing-ip-properties-for-virtual-machines.html
[9] Microsoft: What Is New in Hyperconverged Deployments of Azure LocalCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/whats-new
[10] Microsoft: Overview of Azure Migrate Based VMware Migration for Azure LocalCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/migrate/migration-azure-migrate-vmware-overview
[11] Microsoft: Review Requirements for VMware VM Migration to Azure Local Using Azure MigrateCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-vmware-requirements
[12] Microsoft: Migrate VMware VMs to Azure Local Using Azure MigrateCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-vmware-migrate
[13] Microsoft: Protect VM Workloads with Azure Site Recovery on Azure LocalCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/azure-site-recovery
[14] Microsoft Q&A: Test Migration Functionality for VMware VM Migration to Azure Local Using Azure MigrateCanonical URL: https://learn.microsoft.com/en-us/answers/questions/5818149/test-migration-functionality-for-vmware-vm-migrati
[15] Nutanix: Nutanix Move 6.2 User GuideCanonical URL: https://portal.nutanix.com/docs/Nutanix-Move-v6_2%3ANutanix-Move-v6_2
[16] Nutanix: Nutanix Disaster Recovery GuideCanonical URL: https://portal.nutanix.com/docs/Disaster-Recovery-DRaaS-Guide-vpc_7_5%3ADisaster-Recovery-DRaaS-Guide-vpc_7_5
[17] Broadcom Community: SRM Between Clusters or Sites with Different ESXi VersionsCanonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/srm-between-clusterssites-with-different-esxi-versions
[18] Microsoft Q&A: Migrate from Azure Local to Azure VMCanonical URL: https://learn.microsoft.com/en-us/answers/questions/5914491/migrate-from-azue-local-to-azure-vm
[19] Broadcom: VCF Management Plane IsolationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/using-on-premises-ransomware-recovery/guidelines-for-adding-cyber-recovery-to-an-existing-disaster-recovery-site/vcf-management-plane-isolation.html
How to Deploy NVIDIA vGPU on VMware vSphere and Validate the Configuration
TL;DR Deploying NVIDIA vGPU on VMware vSphere is not simply a matter of installing a driver and attaching a virtual PCI device….
The post Recovery During Platform Transformation: Protecting Mixed Versions, Mixed Hypervisors, and In-Flight Migrations appeared first on Digital Thought Disruption.