By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
A storage controller at your primary site is throwing errors and you have a ninety minute maintenance window. The recovery plan dialog is open and it wants one decision: planned migration, or disaster recovery. Pick wrong in one direction and you lose the last few minutes of transactions you never had to lose. Pick wrong in the other and you burn the whole window waiting on a graceful shutdown that never completes, because the array is already half gone. Same plan, same virtual machines, two very different mornings.
Planned migration, failover and failback are not three features you configure. They are three intentions wired into one recovery plan in VMware Live Site Recovery, the disaster recovery engine that used to be called Site Recovery Manager. The plan you built does not change between them. What changes is whether you are willing to wait for a clean shutdown, whether the source site is even there to shut down, and which way replication runs once the dust settles. Get those three questions right and the radio buttons stop being frightening.
One plan, three intentions
You build a recovery plan once. It names the protected virtual machines, the order they power on, the network they land on, and the scripts that run between tiers. Planned migration and disaster recovery failover both execute that same plan. The VMware Live Recovery documentation is blunt about it: the two modes run the same recovery plan, and the difference is intent. Disaster recovery failover exists for the event where the site is already down and the only goal is to get workloads running again fast. Planned migration exists for the preventive case, where the site is still healthy and you can afford an orderly, lossless move.
Failback is the third intention, and it is the one people underestimate. It is not a button labelled failback. It is a reprotect operation followed by a planned migration that runs the original plan in reverse, and then a second reprotect to put you back where you started. Three operations, one plan, and a lot of room to leave your estate in a half-reversed state if you stop early.
| Operation | When you run it | Data loss | Consistency | Behavior on error |
|---|---|---|---|---|
| Planned migration | Source still healthy: maintenance, preventive move | None | Application consistent | Halts and waits for you |
| DR failover | Source already down or failing | Up to your RPO | Crash or file consistent | Pushes through and continues |
| Failback | After the source site is rebuilt and healthy | None (reverse planned migration) | Application consistent | Halts and waits for you |
Planned migration, the graceful path
What actually happens
Planned migration does something disaster failover never does: it shuts the source virtual machines down first. VMware Live Site Recovery quiesces and powers off each protected VM at Site A, waits for replication to flush the final delta so the copy at Site B is complete, and only then powers the machines up at the recovery site. Because the guest was shut down cleanly before the last sync, the recovered VM is application consistent. There is no torn write, no half-committed transaction, no filesystem check on boot. The documentation states it plainly: planned migration produces an application consistent copy with no data loss.
Where it stalls, and why that is the point
Planned migration halts on the first error and waits for a human. If a VM refuses to shut down, if a datastore is unreachable, if a final sync will not complete, the workflow stops and shows you the failed step. People read that as fragility. It is the opposite. A planned migration that stops is protecting you from recovering an inconsistent copy. The tradeoff is time. You are paying for the graceful shutdown and the final flush with minutes on the clock, and that is exactly why you do not reach for this mode when the site is already burning.
DR failover, the button for when the site is already gone
Disaster recovery mode assumes the source is not coming to the phone. It does not try to shut the protected VMs down gracefully, because it cannot count on reaching them. It powers up the last replicated copy at the recovery site as fast as the plan allows. The consistency you get is whatever the replication layer last captured. With vSphere Replication that is a crash consistent point in time, unless you configured VSS quiescing for Windows guests, in which case you get application consistency at the cost of a heavier snapshot. Array based replication consistency depends on your storage vendor. Either way, you accept losing up to one RPO of changes, which is the whole reason Part 2 told you to pick that number carefully.
The behavioral difference that bites people is this: disaster recovery failover continues even when steps fail. A VM that will not power on does not stop the plan. The workflow logs the failure and moves to the next machine, because in a real disaster you want everything that can come up to come up. There is also a stronger variant, forced recovery, for the case where the protected site is partially alive and its half responses are hanging the workflow. Forced recovery stops trying to coordinate with the source and just recovers. It is only offered in disaster recovery mode, never in planned migration, and you reach for it when the source site is dragging your recovery down with it.
Failback is a round trip, not a reverse button
Reprotect comes first
After a failover, your workloads run at Site B and nothing is replicating anywhere. You cannot fail back until you reprotect. Reprotect reverses the replication direction so that Site B, now the active site, replicates to Site A, and it remaps the virtual machines back to their original folders, port groups, and resource pools at A. Only once B is replicating to A and the copy is seeded can you run a planned migration in reverse to move production home cleanly.
Here is the part that decides whether failback takes two hours or two days. If Site A still holds its old data, reprotect only has to ship the delta that changed while you were failed over. If Site A was rebuilt, or its storage was wiped in whatever caused the outage, reprotect has to seed a full base copy from scratch. That is a full replication of every protected VM back across the link, and it is the single largest hidden cost of a real failover.
The second reprotect people forget
Once the reverse planned migration lands production back at Site A, replication is still running B to A, which is backwards for normal operation. You need a second reprotect to flip it back to A protecting to B. Skip it and you are running production unprotected in the wrong direction, and the next incident finds you with no recovery target. The vendor workflow includes that step. Automation and tired operators at 4 a.m. sometimes do not.
| Link (usable) | Full base resync, 12 TB | Delta resync, 480 GB |
|---|---|---|
| 1 Gbps (about 700 Mbps) | ~38 hours | ~1.5 hours |
| 10 Gbps (about 7 Gbps) | ~3.8 hours | ~9 minutes |
Common objections
Failover is faster, so why not always use it? Because faster to click is not faster to recover a healthy service. Disaster failover skips the graceful shutdown and gives you a crash consistent copy that may need filesystem checks or database recovery on boot, plus whatever you lost since the last RPO. When the source is alive, planned migration reaches a clean state that you can trust, and the extra minutes are cheaper than a corrupt database.
Can I just fail back by running the plan the other way? No. Nothing is replicating toward your old site after a failover, so there is nothing to fail back to yet. You must reprotect first, which reverses replication and reseeds the copy at the original site. Only then does the reverse planned migration have a current copy to move home.
Why is my failback taking a full day when failover took twenty minutes? Almost always because reprotect is seeding a full base copy rather than a delta. If the original site lost its storage in the incident, there is no old data to build on and every protected byte has to cross the link again. Size your recovery link for the full resync, not just for steady state replication.
Does planned migration really guarantee zero data loss? For the migration itself, yes, because the guests are shut down cleanly and the final delta is flushed before recovery. The caveat is that it only completes if every step succeeds. A guest that will not quiesce stops the workflow, which is the mechanism that keeps the guarantee honest.
Where this leaves you
Three intentions, one plan. Planned migration when the source is healthy and you want zero loss. Disaster failover when the source is gone and speed is the only thing that matters. Failback as a four step round trip whose real cost is decided by whether your source storage survived. Put those rules in your runbook now, while nobody is paging you, so the 2 a.m. version of you does not have to reason them out under a failing controller. Next, open your recovery plan and run one honest planned migration test against your fussiest guests, then check that your reprotect direction is written down and automated.
Coming up in Part 10, ransomware recovery and isolated recovery environments, where the copy you fail over to might be the one thing the attacker was counting on you to trust. For the wider picture, the VMware Live Recovery for VCF 9 complete guide maps every part, and if you run this estate day to day, the VCF 9 Operations guide and the VCF automation guide sit right next to this series.
« Previous: Part 8 | VMware Live Recovery Complete Guide | Next: Part 10 »
References
VMware Live Recovery Frequently Asked Questions, January 2026
Broadcom TechDocs, Perform a Failback (VMware Live Site Recovery)
Broadcom TechDocs, Performing a Planned Migration or Disaster Recovery by Running a Recovery Plan
About The Author
DrJha