Recovery During Platform Transformation: Protecting Mixed Versions, Mixed Hypervisors, and In-Flight Migrations

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.

Concern	Migration plan	Recovery plan
Primary objective	Move a workload to a target state	Restore an acceptable business service
Normal trigger	Scheduled wave or cutover	Failure, corruption, cyber event, or failed cutover
Data movement	Seed, synchronize, convert, and cut over	Restore, replicate, fail over, or reconstruct
Success condition	Workload runs on the destination	Business service meets recovery acceptance criteria
Source handling	Usually retained until cutover	May remain the recovery authority for weeks or months
Destination handling	Prepared as the target	Must be independently recoverable
Testing	Test migration or pilot cutover	Restore test, failover test, clean-room test, and application validation
Network changes	Planned mappings and new addresses	Emergency network activation and dependency restoration
Failure response	Retry, reschedule, or roll back	Recover source, recover target, or reconcile divergent data
Evidence	Migration logs and acceptance results	Recovery 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]

Term	Practical interpretation during transformation
VMware Site Recovery Manager	Historical 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 Recovery	Name used by the 9.0.x site recovery orchestration releases.
VMware Live Recovery	The former recovery portfolio and, beginning with later 9.0 releases, the converged appliance containing several protection services.
VCF Protection and Recovery	Current VCF 9.1 product family and documentation terminology.
vSphere Replication	VMware hypervisor-based, VM-centric replication technology. It remains a distinct replication service even when delivered through a converged appliance.
Array-based replication	Storage-system replication integrated with recovery orchestration through a vendor-provided Storage Replication Adapter.
vSAN Protection and Recovery	VCF capabilities for snapshots, replication, retention, and associated recovery workflows involving vSAN.
Advanced Cyber Compliance	Additional 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:

1. Source-platform protection.
2. Migration or conversion replication.
3. Destination-platform protection.
4. 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 phase	Recovery objective	Source controls	Destination controls	Required evidence	Exit condition
Discovery and assessment	Avoid reducing existing recoverability	Preserve backup schedules, DR plans, retention, and monitoring	None required yet, but target requirements are documented	Source restore evidence, application inventory, dependency map	Every in-scope workload has an identified current recovery method
Target design	Ensure the target can support required recovery outcomes	Maintain source protection	Select target backup, DR, cyber recovery, and management recovery designs	Compatibility records, RTO and RPO mapping, capacity model	Target recovery architecture is approved
Target build	Establish a recoverable target platform	Continue source protection	Protect management plane, configure backup infrastructure, build recovery networks	Platform backup, configuration exports, control-plane restore procedure	Target platform can be reconstructed or restored
Pilot replication	Prove data transport without changing the recovery authority	Source remains authoritative	Prepare temporary test protection	Replication health, snapshot impact, network mapping, test logs	Pilot data reaches the target without damaging source protection
Pilot migration	Validate conversion and workload operation	Retain source backup and rollback capability	Perform isolated destination backup and restore	Application test, data validation, destination restore report	Pilot workload is operational and independently recoverable
Production waves	Maintain two viable recovery paths	Keep source backup and DR active	Start target protection immediately after each cutover	Per-wave backup success, restore sample, monitoring coverage	Every migrated workload has destination protection
Coexistence	Control split ownership and mixed recovery	Monitor remaining source workloads	Monitor migrated target workloads	Unified dashboard, ownership register, unresolved exception list	No workload is unowned or protected only by a temporary migration tool
Final cutover	Recover from partial or failed transition	Preserve last source restore point and rollback state	Capture target recovery point before business writes where possible	Final synchronization evidence, validation results, decision log	Business owner accepts target service
Stabilization	Prove target recovery under normal operations	Retain source copies according to rollback policy	Test destination restore, failover, and cyber controls	Measured RTO and RPO, application signoff, support handoff	Destination recovery objectives are demonstrated
Decommissioning	Retire obsolete protection safely	Remove jobs only after approval, retain required archives	Confirm target retention and compliance coverage	Decommission checklist, legal retention decision, evidence archive	Original 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 attribute	Example questions
Current backup	Which product, repository, policy, and retention period protect it?
Current replication	Is it protected by vSphere Replication, array replication, application replication, or another mechanism?
Application consistency	Is VSS, database quiescing, log backup, or application-native protection used?
Recovery target	Can it recover only to the source platform, or also to an alternate platform?
Recovery dependencies	Which domain controllers, DNS servers, certificate authorities, secrets, networks, and databases are required?
Last successful test	When was it restored or failed over, and what actually passed?
Rollback limit	How long can the source remain authoritative after target cutover?
Data divergence risk	Can 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:

Field	Required evidence
Protected-site platform	Exact vCenter and ESXi versions and builds
Recovery-site platform	Exact vCenter and ESXi versions and builds
Recovery orchestration	Exact SRM, VMware Live Site Recovery, or Protection and Recovery release
Hypervisor replication	Exact vSphere Replication and add-on server builds
Storage replication	Array model, firmware, replication software, and SRA version
Backup integration	Backup server, proxy, transport, agent, and plug-in compatibility
Upgrade path	Direct, stepped, or appliance-convergence path
Validation date	Date the vendor matrices were checked
Evidence owner	Person accountable for rechecking before execution
Change trigger	New 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 method	Best fit	Primary strengths	Transformation limitation
Array-based replication	Low-RPO VMware-to-VMware recovery using supported storage platforms	Storage consistency groups, efficient data movement, array-native capabilities	Depends on array, firmware, SRA, datastore, and recovery-product compatibility; normally does not convert workloads to another hypervisor
vSphere Replication	VM-centric VMware recovery across heterogeneous storage	Storage-independent at the VM level, configurable RPO, orchestration integration	Remains a vSphere technology and is not a general cross-hypervisor conversion engine
Migration-tool replication	Moving and converting workloads to Azure Local, AHV, cloud, Hyper-V, or another target	Discovery, seeding, delta synchronization, network mapping, conversion, planned cutover	Often lacks long-term retention, point-in-time recovery depth, cyber isolation, and established DR orchestration
Backup-based migration	Low-change or difficult workloads, archive migration, controlled restore	Independent recovery copy, retention, portability where supported	Longer cutover and restore times; application reconfiguration may be required
Application replication	Databases, messaging, file services, and stateful applications	Application-aware consistency and controlled role transition	Protects the application but not necessarily the VM, platform configuration, or shared dependencies
Storage or file synchronization	Large datasets and content repositories	Efficient movement of data independently of compute	Does 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 type	Minimum validation
Stateless web tier	Configuration, secrets, image version, load-balancer registration, and dependent API access
Windows application	VSS behavior, service ordering, certificate access, and domain authentication
SQL database	Database consistency checks, transaction-log recovery, listener or connection-string validation
Linux database	Database-native backup or quiescing, journal recovery, service dependencies
File service	File-system consistency, permissions, locks, namespace, and client access
Directory service	Replication health, role ownership, time, DNS, and authoritative restore considerations
Clustered application	Quorum, shared storage, fencing, node identity, and supported recovery order
Message queue	Durable-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:

1. Validate current recovery.
2. Establish version-compatible recovery orchestration.
3. Upgrade or build the destination management plane.
4. Validate site pairing and replication.
5. Test recovery with representative workloads.
6. Move migration waves.
7. Establish destination protection.
8. 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

Phase	RPO interpretation	RTO interpretation
Before replication	Existing source RPO	Existing source recovery procedure
Initial seed	Source backup remains authoritative	Source recovery remains primary
Continuous synchronization	Migration lag is measured separately from recovery RPO	Target startup is not yet an accepted RTO
Pilot cutover	Source rollback point plus pilot target state	Includes conversion and validation time
Production coexistence	RPO differs by workload location	Recovery tool and owner depend on workload state
Post-cutover before target backup	Potentially highest risk	May require rollback or forward recovery
Destination protected	Target-native RPO	Target-native recovery workflow
Source retired	Target and cyber-recovery objectives only	Source 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:

1. Where is the authoritative workload running?
2. Which recovery policy currently protects it?
3. Is replication or backup meeting its objective?
4. Can the copy be recovered?
5. 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:

1. Freeze new source protection-group membership.
2. Confirm no active workloads depend on the source recovery plan.
3. Export configurations and recovery histories.
4. Retain required backup sets.
5. Remove source replication relationships.
6. Clean migration snapshots and temporary artifacts.
7. Revoke migration credentials.
8. Remove temporary firewall rules.
9. Retire source backup jobs.
10. Remove obsolete repositories only after retention expires.
11. Decommission recovery appliances and plug-ins.
12. Remove stale DNS, certificates, service accounts, routes, and monitoring objects.
13. Update the configuration management database.
14. 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