The VMware Migration Playbook: A Practical Framework for a Controlled Migration

How to Use This Playbook

Begin with the decisions already made and make the remaining work explicit.

The modernization guide helps an organization choose its desired operating model and evaluation approach. This playbook carries that decision into workload planning, testing, cutover, and operational acceptance. Vendor-specific commands belong in tested runbooks attached to the plan.

Bring forward the modernization decisions

Starting here without the guide? Complete Phase 1 and the discovery questionnaire before scheduling migration. If destination selection is unresolved, keep it as an explicit decision with an owner and evidence requirement.

Use the phases and tools together

1. Read the gate model in Migration Gates and Decision Rights. Phases 1–6 establish readiness; Phases 7–9 cover execution and operations. Phase 10 applies throughout.
2. Complete the named outputs for each phase. Store evidence under stable workload, application, wave, risk, and decision IDs.
3. Use the fictional worked example to see how records connect. Copy the blank tools (Tools A–N, at the end of this playbook) into your project workspace.
4. Approve G4 once for the defined production scope, then release each wave separately. Reopen earlier gates when the scope, architecture, method, or risk materially changes.

Completion standard: a workload is complete when application behavior, data, controls, recovery, and operating ownership have been accepted—not simply when the VM boots.

Migration Gates and Decision Rights

A gate authorizes the next defined activity; it does not waive later checks.

Wave release: after G4, the change authority authorizes each specific wave using current readiness, capacity, runbook, application-owner availability, and rollback evidence. Use Tool M. G4 is not a standing approval for every future change.

Decision options: approve; approve with documented conditions satisfied before execution; hold; or stop. An approval record names the approver, scope, evidence, conditions, and date. Conditions affecting safety must be closed before the authorized action.

Gates are scoped. An unresolved workload can be retained or deferred while a validated group proceeds. Reapproval is required when new evidence changes the approved risk or design.

1. Establish the Migration Program

Turn the modernization decision into an owned, funded scope.

Accountable owner: Executive sponsor; program manager prepares the charter.

Start with: Modernization objectives, contract dates, candidate destinations, and economic baseline.

Produce: Program charter, success measures, responsibility assignments, and initial decision log. Tools L, M, and N.

Proceed when: G0 records who may begin discovery, what is in scope, and what resources are available.

Write the charter before committing the schedule

Define measurable success

For every measure, record the baseline period, target, measurement method, owner, and approval threshold. Include outage duration, application tests, data consistency, performance, recovery, monitoring coverage, and support acceptance. Tool J holds the test record; Tool N holds financial assumptions.

Do not treat a fixed deadline as evidence of readiness. If validation cannot finish in time, the sponsor must choose a smaller scope, a revised window, continued source operation, or another viable path.

First working session

• Name one accountable owner for each decision and each production service. Fill Tool L with actual names and backups.
• Identify unresolved destination decisions and assign evidence, an owner, and a deadline.
• Agree how scope changes and risk exceptions reach the sponsor. Record the G0 decision in Tool M.

2. Discover Workloads and Dependencies

Create a reliable system of record for the migration.

Accountable owner: Technical owner; discovery lead coordinates domain and application owners.

Start with: Authorized access, scope, source inventories, CMDB, monitoring, backup, and network records.

Produce: Reconciled workload inventory, dependency records, requirements, and exception list. Tools B and C.

Proceed when: G1 confirms sufficient evidence to design; unknowns have owners and a defined treatment.

Capture the migration estate

Record where evidence came from and when it was collected. Configured vCPU and memory describe allocation; measured utilization and peak demand inform capacity planning. Keep both.

Disposition stale, powered-off, orphaned, and unknown workloads explicitly. A missing owner is an unresolved decision, not permission to delete the workload.

Verify Dependencies and the Baseline

An accurate VM list does not prove that an application can move. Review the service as a dependency group, including shared systems that may remain on VMware or another platform.

Build the dependency record

Reconcile before designing

1. Compare platform inventory with CMDB, backup, monitoring, and owner records. Resolve discrepancies or isolate them as exceptions.
2. Validate dependency assumptions using configuration, observed traffic, and application-owner review. Include batch jobs, license servers, queues, shared files, and external integrations.
3. Capture performance across representative peaks and business cycles. Record observation gaps rather than extrapolating from a quiet sample.
4. Identify source-specific requirements: virtual appliances, encryption/key services, shared storage patterns, host-bound licenses, GPU or device access, and automation interfaces.
5. Confirm which application tests prove service health and who will run them during the change window.

G1 evidence package

Submit the inventory with owner coverage, dependency map, business and recovery requirements, baseline measures, and a list of unknowns. Each unknown needs an owner, due date, impact, and disposition. Do not schedule an affected production workload while a critical prerequisite remains unresolved.

Output link: use the same workload and application IDs in Tools C, D, G, H, J, and K. This prevents a successful VM task from being mistaken for acceptance of the whole service.

3. Classify Workloads and Assess Compatibility

Separate the business destination from the method used to reach it.

Accountable owner: Technical owner; application owners confirm service requirements.

Start with: Inventory, dependencies, business constraints, and baseline observations.

Produce: A disposition, risk profile, compatibility status, and proposed method for each workload group. Tool D.

Proceed when: Classification supports G2 design; blockers are retained, deferred, resolved, or explicitly removed from scope.

Assign an explicit disposition

Do not turn a combined risk score into an automatic migration order. A technically uncertain low-criticality workload may be less suitable for an early wave than a critical workload with a well-proven method.

Prove Compatibility for Each Workload Class

A workload class groups systems with materially similar guest, storage, network, application, and recovery behavior. Select representative and exception cases; similarity in VM names or sizes is insufficient.

Keep the evidence specific

Record source and target products and versions, tool version, guest configuration, architecture, tested actions, results, exclusions, and evidence date. A successful test applies to that defined combination; material changes require impact review and, where needed, retesting.

Handle exceptions before wave scheduling

• Write the exact incompatibility and affected services in Tool E. Assign an owner and a decision date.
• Evaluate alternate methods, architecture changes, continued source operation, or a different destination.
• Do not use roadmap features or an untested integration to close a production blocker.
• Use Tool D to link compatibility evidence to the selected method and Tool J to record the acceptance tests.

Boot success and disk conversion are intermediate checks. Production compatibility also includes application behavior, data, performance, controls, recovery, and operating support.

4. Design the Target and Coexistence

Design how services will operate during and after the move.

Accountable owner: Technical owner; domain owners approve their designs.

Start with: Classified estate, service requirements, capacity baseline, and candidate methods.

Produce: Target design, coexistence plan, capacity model, protection design, and assigned support boundaries.

Proceed when: G2 accepts a viable design and a bounded plan to resolve remaining validation questions.

Capacity must include the transition

• Model peak demand plus agreed failure and maintenance headroom; record assumptions and growth.
• Include temporary test copies, conversion staging, snapshots, backups, replication, and retained source resources.
• Validate representative application response, storage latency, and network behavior under realistic load.
• Reserve people and support capacity as well as hardware. A wave is limited by what the team can validate and recover.

G2 accepts the design for test planning. It does not establish production readiness; G3 authorizes testing and G4 evaluates the resulting evidence.

Design the Period of Parallel Operation

Fund the transition explicitly

Use Tool N to track parallel licenses and support, temporary capacity, tools, network transfer, partner effort, internal labor, and contingency. Record quantities, rates, duration, evidence, and an owner. Link overlap duration to wave progress and source retirement gates.

Distinguish cash savings from released labor capacity, cost avoidance, and future benefits. Retiring a VM does not necessarily reduce a contract bill; verify the applicable commercial conditions before recording savings.

Review the combined design

Walk through a service failure while workloads span both environments. Confirm who detects it, who diagnoses it, what can be restored, where the data authority sits, and who can authorize recovery. Resolve responsibility gaps before G3.

Operational contracts, support statements, and current product documentation should be attached to the design where they determine feasibility. This playbook does not substitute for those commitments.

5. Select Migration Methods

Choose a method for each service or workload class.

Accountable owner: Migration lead, with technical-owner approval.

Start with: Compatibility findings, outage limits, target design, data requirements, and available tooling.

Produce: Method decision record, tested runbook design, outage budget, and rollback plan. Tools D, H, and I.

Proceed when: G3 has a safe test plan; G4 later requires evidence that the chosen methods meet production requirements.

Use this selection sequence

1. Confirm whether the workload should move, be rebuilt, be replaced, be retired, or remain.
2. Evaluate reproducible redeployment; then restore or conversion if the outage budget allows.
3. For shorter outages, test supported replication or application-native methods. Include final sync and validation in the outage estimate.
4. If no validated method meets the requirement, redesign, change the approved window, retain, or defer. Record the decision in Tool D.

No method implies universal compatibility or zero downtime. The runbook must name exact products, versions, prerequisites, commands or procedures, and support arrangements.

Design Rollback Before Cutover

Rollback is a recovery operation with its own data, time, and resource constraints. Separate recovery before target writes from recovery after the destination has accepted new transactions.

Budget the decision time

Latest safe rollback decision = end of the approved outage window − tested rollback duration − agreed contingency. Also stop earlier if a data-authority or consistency boundary would invalidate the recovery plan. Record both time and state limits in Tool I.

Define triggers and authority

• Use explicit thresholds for data mismatch, application failure, security-control failure, performance, protection, and elapsed time.
• Name the go/hold/rollback authority and backup. Define who may stop an unsafe action immediately and how it is escalated.
• Record source isolation, credentials, capacity, required licenses, network changes, and recovery personnel.
• Rehearse the rollback path and capture elapsed time. If a production-safe rehearsal is not possible, document the limitation and resolve the resulting approval question before execution.

Plan communications and data custody

Specify who announces the interruption, status updates, recovery decision, and restored service. Keep logs and evidence in an access-controlled location. Use references to approved secret stores rather than putting credentials in runbooks.

The rollback retention period and the safe rollback decision point are different. Keeping a source VM for seven days does not make a seven-day rollback safe.

6. Pilot the Design

Use a bounded test to resolve the production decision.

Accountable owner: Technical owner; migration lead runs the pilot.

Start with: G2 design, representative workloads, exact methods, acceptance tests, and rollback design.

Produce: Pilot charter, test evidence, defect dispositions, measured timings, and a G4 recommendation. Tools F, I, J, and M.

Proceed when: G3 authorizes the test; G4 requires demonstrated readiness for the defined production scope.

Select representative conditions

Run the pilot as a decision process

1. Approve the charter, test isolation, data handling, scope, and stop conditions at G3.
2. Rehearse forward migration and recovery. Log actual durations, deviations, and prerequisite failures.
3. Compare agreed acceptance tests with the source baseline under representative conditions.
4. Record defects by affected workload class. Retest fixes and identify changes that require wider regression.
5. Recommend proceed, extend for a named evidence gap, defer to a prerequisite, or stop. The sponsor records the production decision at G4.

Pilot approval does not authorize unrestricted production workloads. If a pilot includes production service, it must also satisfy the applicable production change and business approvals.

Validate the Service and Its Operating Model

Use thresholds rather than impressions

Each test needs a workload/service ID, preconditions, baseline, acceptance threshold, test method, owner, actual result, evidence reference, and pass/fail/exception status. Tool J supplies the record. A completed backup job is not evidence that a restore works.

Prepare the G4 recommendation

Attach the scope and architecture tested; method and version records; forward and rollback timings; application, security, and operations sign-offs; closed critical defects; bounded exceptions; and the proposed first-wave plan. State what the pilot did not establish.

If the destination, tooling, workload configuration, or recovery method changes after the pilot, assess whether the evidence still applies. Reopen the relevant gate before relying on it.

7. Plan Migration Waves

Group work around service dependencies and recovery capacity.

Accountable owner: Migration lead; change authority releases each wave.

Start with: G4 approval, validated methods, dependency groups, support capacity, and business windows.

Produce: Wave plan, service roster, readiness evidence, change record, and cutover runbook. Tools G, H, and M.

Proceed when: Every wave has current release approval; unresolved critical prerequisites remain outside the wave.

Separate readiness from scheduling

A workload can be assigned to a tentative wave before it is ready. Use distinct statuses: proposed, blocked, ready for release, released, executing, stabilizing, accepted, and retired. Only the named change authority may release the wave.

At release, verify the exact workload list, owners and backups, current capacity, security/protection readiness, runbook version, rollback limits, approved exceptions, and communications. A material change to the released list requires review.

Review after each wave

Record actual outage, validation defects, recovery events, operator effort, incidents during stabilization, and lessons. Pause comparable waves when a defect could recur; do not let throughput targets override evidence.

Execute the Cutover Runbook

Tool H separates the reusable procedure from the live execution log. Every actionable step must point to an exact approved procedure and record an owner, prerequisite, expected duration, success check, stop condition, and recovery action.

Keep execution controlled

• Log planned and actual times with a time zone. Preserve command/output references and deviation records.
• Do not improvise a new method during the window without a hold and the required technical/change approval.
• Track the remaining recovery budget visibly. A successful conversion can still require rollback if validation cannot finish safely.
• Avoid concurrent writers or duplicate network identities. Assign one authoritative service state at every step.

Source retirement is a later G6 decision. Completing cutover does not authorize deletion of rollback resources or removal of shared source services.

8. Accept Production and Retire the Source

Close service acceptance and source retirement as separate decisions.

Accountable owner: Production service owner for G5; source service owner for G6.

Start with: Cutover log, validation evidence, stabilization results, defects, and recovery records.

Produce: Signed production acceptance, operations handoff, and a separate retirement authorization. Tool K.

Proceed when: G5 accepts the service; G6 independently clears source removal.

Before G6 source retirement

• Confirm no remaining workload, integration, automation, license service, backup, or recovery process depends on the source object.
• Verify required archives, backups, logs, records, and retention approvals. Confirm the target recovery path is independently usable.
• Revoke or update credentials, agents, network rules, monitoring, and asset records without disrupting retained systems.
• Record commercial conditions before claiming license or support savings. Reclaim capacity deliberately.
• Obtain approval for the specific resources to remove and retain evidence of the completed retirement.

An expired retention date is a review trigger, not an automatic deletion instruction. The G6 approver confirms that the conditions still hold at removal time.

A service accepted with an exception must have a bounded issue, accountable risk approver, treatment, and due date. Use hold when a critical acceptance condition is unmet.

9. Operate and Improve the Destination

Measure the operating outcomes promised by modernization.

Accountable owner: Production service owner; domain teams perform ongoing operations.

Start with: G5 acceptance, support arrangements, service baselines, and open improvements.

Produce: Operating reviews, verified protection, updated capacity forecasts, and measured benefits. Tools J, K, and N.

Proceed when: Migration control ends only after ownership is accepted; ongoing reviews track service health and improvement.

Use 30 60 and 90 day reviews

At 30 days, confirm stability, support ownership, and protection. At 60 days, review recurring incidents, capacity, and operational friction. At 90 days, compare observed outcomes with the modernization baseline and assign the next improvements. Adapt these intervals to the service’s business cycles.

Keep migration measures separate from operating measures. A short outage does not prove better provisioning, fewer incidents, lower cost, or more useful capacity. Use the relevant baseline and observation period for each claim.

Retire tools and manual processes only after their replacements and responsibilities are proven. Record actual savings and cost avoidance separately in Tool N.

10. Govern Risk and Migration Progress

Apply these controls throughout all phases.

Accountable owner: Executive sponsor; program manager maintains the decision and evidence records.

Start with: Gate status, wave progress, defects, risk records, economic assumptions, and upcoming deadlines.

Produce: Current risk register, decision log, weekly dashboard, and explicit escalation actions. Tools E, M, and N.

Proceed when: Decisions have owners, evidence, and dates; unresolved risk is visible before execution.

Escalate the conditions that change the plan

Escalate incomplete discovery, compatibility blockers, data inconsistency, control failures, recovery gaps, unsupported methods, capacity shortfalls, or an unavailable decision owner. Also escalate any delay that threatens a contract or business deadline.

Disposition options are close, mitigate, accept, transfer, avoid, or defer. Record residual risk and the accountable approver. Transferring work to a partner does not remove the organization’s need to accept the service outcome.

A production blocker is not closed by a vendor roadmap statement. Require available capability and evidence for the actual design, or change the scope or destination.

Worked Example: From Discovery to Pilot

Fictional planning example only. Values and results are illustrative, not customer evidence.

Meridian Supply is a fictional distributor moving its OrderDesk service from VMware to an unspecified, supported VM destination. The service has two application VMs and one database VM. The destination remains vendor-neutral so the example demonstrates the planning method.

Resolve a discovery finding

RISK-017 identifies an undocumented outbound queue consumer. Moving the database without pausing it could produce incomplete processing. The application owner adds its endpoint, credentials reference, pause/resume procedure, and reconciliation test to DEP-03 and Tool J. G1 closes only after the dependency is owned.

Choose and pilot the method

DEC-017 selects application rebuild plus database restore because the fictional service has a sufficient planned window and a supported, reproducible workflow. The pilot uses a representative protected copy, isolated endpoints, and test credentials. It exercises application transactions, queue sequencing, target protection, and rollback before production writes.

Illustrative pilot results: final backup 15 minutes; restore 25; service start 10; validation 15; traffic release 5. Tested source recovery takes 30 minutes. These are example observations, not duration estimates for other environments.

Worked Example: Wave Release and Cutover

Fictional example continued. All thresholds and timings are illustrative.

WAVE-01 contains only APP-017 and its three workloads. G4 approves this tested scope. CHG-017 releases the wave after domain owners confirm readiness, the application owner joins the bridge, and the source remains recoverable. RUN-017 links every step to the tested procedure and evidence.

Define the recovery boundary

With a 120-minute outage, 30-minute tested source recovery, and 15-minute contingency, the latest time-based rollback decision is T+75. A state boundary applies sooner: once target production writes are enabled at T+65 in the successful path, the team must use the approved recovery/reconciliation plan rather than restart a stale source.

Alternate failure branch: if validation fails at T+55 while target production writes remain blocked, hold and decide by T+60. Fence the target, restore source traffic and jobs, validate the source, and recover by T+90 using the rehearsed 30-minute procedure. This branch is an alternative to the successful path, not an additional step.

Do not copy the timing into a real change window. Replace every duration, data boundary, and acceptance threshold with evidence for the actual service.

Worked Example: Acceptance and Lessons

Fictional example continued. This is a completed-record illustration.

A source copy is not an up-to-date recovery service

The retained source database is stale after target transactions begin. Its seven-day retention supports the agreed evidence and contingency purposes; it does not create a seven-day safe rollback window. Post-write recovery relies on the approved target recovery and reconciliation design.

Update the next wave

The team adds the previously undocumented queue dependency to discovery checks, assigns a dedicated data-owner sign-off before write release, and records the observed durations in the next method plan. A different application or configuration still requires its own compatibility and recovery evidence.

Trace the complete plan

APP-017 and WL-101/102/103 connect the inventory (Tool C), method decision (D), risk (E), pilot (F), wave (G), runbook (H), rollback record (I), tests (J), acceptance (K), owners (L), approvals (M), and overlap cost assumptions (N). A reviewer can follow each production decision back to its evidence.

Tool A: Migration Readiness Checklist

Use at G2 design review, G3 pilot approval, G4 production approval, and every wave release.

Copy for each gate or wave. Mark each item Pass, Fail, Not applicable, or Pending. A pending critical item blocks the relevant action; record the owner and evidence in Tool M.

Record identity
[Gate or wave ID | Scope | Reviewer | Date | Evidence location]

At G2, design and test plans may still contain explicit validation work. At G3, confirm the test is safe to run. At G4 and wave release, require completed evidence for the production scope; a scheduled test is not a pass.

Decision and unresolved items
[Approve / Hold / Stop | Conditions | Owner and due date | Approver and date]

Tool B: Discovery Questionnaire

Use with application and domain owners before closing G1.

Capture answers in the project inventory and evidence repository. This template is an interview record; it does not replace the workload-level inventory.

Interview record
[Service or estate | Owner | Interviewer | Date | Related workload IDs]

Business and timing
[What drives the move? Which deadlines, blackout periods, maximum outage, recovery requirements, and operating outcomes apply?]

Estate and destination
[Which sites, versions, clusters, VMs, special devices, source features, target assumptions, retained systems, and stale workloads are in scope?]

Application and dependencies
[Who owns the service? What databases, queues, APIs, batch jobs, shared files, identity, licensing, and external connections are required?]

Network storage and security
[Which routes, segments, firewall flows, addresses, certificates, keys, storage patterns, privileges, agents, and control obligations must be preserved?]

Protection and operations
[Which backup products/versions and restore tests exist? Who handles monitoring, incidents, patching, recovery, and support after the move?]

Acceptance and unknowns
[Which tests prove the service works? Who performs them? What is unverified, who will resolve it, and by when?]

Tool C: Workload Inventory Record

Create one record per workload and link every record to its application or service.

Use these fields in a spreadsheet or CMDB for larger estates. Retain stable IDs and evidence links across all records; duplicate this record for a small scope.

Never store passwords or secret keys in the inventory. Reference the approved secret store and access owner. Retain excluded and deferred workloads so they remain visible in scope and cost reporting.

Tool D: Classification and Method Record

Complete per service or workload class before G2; update with pilot evidence before G4.

Duplicate this template for each record. Replace bracketed prompts with project information; expand fields as needed.

Scope and authority
[Record ID | Service/workload IDs | Decision owner | Date | Source/target versions]

Method selection checks

• Can the workload be reproducibly redeployed with acceptable data and configuration risk?
• If restore or conversion is selected, does the full outage include validation and recovery decision time?
• If replication is selected, are final sync, write authority, lag, licensing, and post-write recovery tested?
• If no supported method meets the requirement, has retain, defer, or redesign been approved?

Recorded decision
[Selected option | Conditions | Approver/date | Revalidation trigger | Linked risk IDs]

Tool E: Risk and Decision Record

Maintain one record per material risk or exception and link related decisions.

Seed the register with discovery, compatibility, data consistency, network/security, performance/capacity, protection, rollback, ownership, schedule, and integration risks.

Identity and affected scope
[Risk ID | Service/workload/wave IDs | Owner | Opened date | Next review]

Condition and consequence
[Describe the uncertain condition, possible service impact, and evidence that would confirm or close it.]

Linked decision

Decision record
[Decision ID | Options considered | Selected option and reason | Evidence links]

Approval and closure
[Approver/date | Conditions | Retest/closure evidence | Reopen trigger]

Acceptance does not turn an unsupported method into a supported one. Where a risk prevents meeting a mandatory service requirement, change the design or scope, or hold the workload.

Tool F: Pilot Charter

Complete before G3 and attach the resulting evidence to the G4 recommendation.

Duplicate this template for each record. Replace bracketed prompts with project information; expand fields as needed.

Pilot identity and dates
[Pilot ID | Sponsor | Technical owner | Migration lead | Start/end | Decision date]

Scope and representation
[Services/workloads | Workload classes represented | Exclusions | Why this sample is meaningful]

Architecture and methods
[Source/target versions | Design references | Exact method/tool versions | Known validation questions]

Test safety and data
[Isolation | Permitted data | Write/traffic restrictions | Access | Stop conditions | Cleanup]

Decision and responsibilities
[G3 approver | Application/domain owners | Support/escalation | Evidence repository]

Exit recommendation
[Proceed / Extend for named gap / Defer to prerequisite / Stop | Evidence | Conditions | G4 approver]

Tool G: Migration Wave Planner

Separate tentative scheduling from authorization to execute.

Duplicate this template for each record. Replace bracketed prompts with project information; expand fields as needed.

Wave control
[Wave ID | Migration lead | Change record | Window/time zone | Release authority]

Sequence and shared dependencies
[Move order | Prerequisites | Cross-platform dependencies | Source/target write authority]

Capacity and people
[Target/staging/recovery headroom | Concurrent service limit | Test owners and backups | Support coverage]

Time and recovery budget
[Forward steps | Validation | Decision deadline | Recovery duration | Buffer | Approved end]

Release evidence
[Tool A status | Tool H runbook/version | Tool I rollback | Tool J tests | Exceptions | Tool M approval]

Communications and stabilization
[Stakeholders | Status cadence | Bridge | Escalation | Monitoring period | Exit owner]

Wave results and learning
[Actual outage | Defects/incidents | Acceptance references | Changes required before next wave]

Status values: proposed, blocked, ready for release, released, executing, stabilizing, accepted, retired. Retained/deferred workloads remain visible in the overall inventory.

Tool H: Cutover Runbook Definition

Part 1 of 2. Complete the control sheet and duplicate the step record for every actionable step.

This is the execution procedure, not a list of general migration phases. Attach exact vendor/product procedures and tested commands to each step.

Runbook control
[Runbook ID/version | Service and wave IDs | Change ID | Procedure owner | Approval/date]

Window and authority
[Start/end/time zone | Go/hold/rollback authority and backup | Bridge | Escalation]

Entry conditions
[Approved G4/wave release | Workload list | Prerequisites | Target health | Data/traffic state]

Recovery limits
[Latest decision time | Data-state boundary | Tool I record | Tested duration | Recovery resources]

Repeatable step record

Use the execution log below to record actual results. Never place credentials in either record. Protect command output and evidence according to their data classification.

Tool H: Cutover Execution Log

Part 2 of 2. Use the approved runbook version and record events as they occur.

Execution identity
[Runbook/version | Wave/change ID | Date/time zone | Log owner | Evidence location]

Deviation or incident
[Timestamp | Affected step | What changed | Service/data impact | Hold action | Incident/decision ID]

Go hold or rollback decision
[Timestamp | Decision and evidence | Approver | Remaining time | Data authority | Tool I link]

Production write release
[Who authorized writes and when | Source fencing evidence | Recovery plan now in force]

Close and handoff
[Service restored time | Actual outage | Stabilization owner | Open defects | Tool J/K links]

Duplicate log rows as needed. A missing result is not a pass. Preserve the original execution history and record corrections with their author and time.

Tool I: Rollback Decision Record

Complete before the test or change window; update at each recovery boundary.

Duplicate this template for each record. Replace bracketed prompts with project information; expand fields as needed.

Recovery scope
[Service/workload IDs | Wave/change/runbook | Recovery lead | Authority and backup]

State boundary and retention
[Event after which simple source return is unsafe | Write-authority control | Source retention purpose and horizon]

Live recovery decision
[Timestamp | Go / Hold / Rollback / Forward recovery | Trigger and evidence | Approver | Data owner]

Recovery result
[Start/end | Data integrity | Service tests | Actual outage | Remaining incidents | Acceptance owner]

If no validated post-write recovery path exists, do not assume that retained source VMs close the gap. Resolve the recovery design before authorizing production writes.

Tool J: Validation Record

Use one record per test; summarize the results for application and gate acceptance.

Create tests for infrastructure, data, application, network, performance, security, protection, operations, and business acceptance. Reference the same test IDs during pilot and production where applicable.

Test identity
[Test ID | Layer | Service/workload IDs | Method/runbook version | Test owner | Date]

Purpose and conditions
[What this test proves | Source/target versions | Prerequisites | Permitted traffic/data/write state]

Baseline and pass threshold
[Observed baseline/period | Exact acceptance threshold | Measurement method | Exception authority]

Procedure and expected result
[Approved steps/reference | Inputs | Expected output | Evidence capture]

Test production write paths only under an approved data plan. Read-only checks before write release may be combined with earlier isolated write-path testing; document exactly what each test establishes.

Tool K: Acceptance and Retirement Record

Record G5 and G6 separately, even when they use the same service record.

Record identity
[Service/workloads | Wave/change | Migration date | Production owner | Source owner]

G5 production acceptance

G5 decision
[Accept / Accept with bounded exception / Hold / Recover | Approver/date | Evidence repository]

G6 source retirement

Specific resources and conditions
[Source objects to remove | No remaining dependencies | Retention approvals | Independent target recovery]

Retirement authorization
[G6 approver/date | Required pre-removal checks | Approved removal window | Commercial/asset handling]

Execution and evidence
[Executor/date | Removal evidence | Inventory/security updates | Reclaimed capacity | Verified financial effect]

Source retention review date: [date and owner]. Retention is not a guarantee of safe rollback after new target transactions. Confirm the recovery plan and data authority separately.

Tool L: Responsibility Matrix

Assign actual names and backups before G0; confirm availability for each change.

The matrix below is a starting allocation. A = accountable for the decision; R = performs or coordinates the work; C = consulted; I = informed. Assign one accountable role per activity, then map the roles to named people. Customer accountability and supplier delivery scope should remain explicit.

* For G6, replace Ops owner with the named source service owner if different. For G5, Ops owner represents the designated production service owner. Security, network, storage, and protection owners approve their domain evidence; they are required participants even though omitted from this compact matrix.

Named role roster
[Role | Primary | Backup | Contact reference | Availability | Approval delegation]

Customer partner and vendor scope
[Who executes each workstream | Statement of work/support references | Service hours | Escalation and exclusions]

Do not assume the platform vendor operates the customer’s source environment or performs migration services. Confirm contracted responsibilities and access before work begins.

Tool M: Gate and Wave Release Record

Use for G0–G6 and for every production wave release.

Duplicate this template for each record. Replace bracketed prompts with project information; expand fields as needed.

Decision identity
[Gate/release ID | Date | Scope/service/wave IDs | Accountable approver | Evidence cutoff]

Requested authorization
[Specific activity permitted | Workload/configuration boundaries | Window | Prior gate references]

Decision
[Approve / Approve with pre-execution conditions / Hold / Stop | Reason | Approver/date]

Conditions and closure
[Condition | Owner | Due date | Closure evidence | Who confirms closure before execution]

Reapproval triggers
[Changes to scope, configuration, method, risk, timing, personnel, or evidence validity that reopen approval]

G4 authorizes production migration for a defined scope. Each wave still needs release. G5 accepts each service into normal operations. G6 authorizes source removal. Link these records; do not substitute one for another.

Tool N: Transition Economics Record

Use actual quotes and measured effort; update after each wave.

Planning basis
[Scope | Baseline period | Currency | Model owner | Quote dates | Approved overlap duration]

Estimate and variance
[One-time total | Recurring overlap total | Actual to date | Forecast at completion | Variance and cause]

Savings and other benefits
[Cash savings | Cost avoidance | Released labor/capacity | Baseline | Trigger | Measurement owner]

Sensitivity and decisions
[Effect of longer overlap, failed waves, retained tools, or changed staffing | Decision owner and date]

Apply consistent units and periods. Do not count internal labor as incremental cash unless it creates additional spend, or count the same item in both the baseline and transition costs. Benefits start when the relevant technical and commercial conditions are actually met.

Synaptix Destination Companion

Apply the same migration gates when Synaptix™ is the selected destination.

MoirAI Cloud positions Synaptix™ as an AI-powered infrastructure operating platform. A Synaptix evaluation should consider the destination’s operating model as well as workload placement: supported compute, networking, storage, service delivery, observability, and governed AI workflows in the proposed deployment.

Use the core playbook for discovery, method selection, pilots, cutover, acceptance, and retirement. A platform choice does not replace workload-specific compatibility and recovery evidence.

Confirm the proposed scope with MoirAI

Capability status: obtain the current approved matrix during evaluation. Confirm release status, supported configurations, and scope in a dated record. Planned, integrating, or unvalidated capabilities cannot satisfy a production gate.

Any proposed Synaptik™ Cell deployment requires its own workload qualification, supported configuration, migration method, isolation, performance, and recovery evidence. Do not assume a VM migration approval also approves Cell adoption.

MoirAI’s role and any migration assistance must be defined in the agreed scope. This playbook does not establish a managed-services or migration-delivery obligation.

Terms and Document References

Keep the plan grounded in dated evidence and named owners.

Document lineage

This edition develops MoirAI Cloud’s VMware Migration Playbook EBG-003 Version 0.1, dated August 2026, into a practical planning and execution reference. It is paired with The Executive Guide to VMware Modernization, First Edition, Version 1.0, August 2026.

Version 1.0 adds explicit phase outputs and gate ownership, per-wave release, working execution and recovery records, a responsibility matrix, transition economics, and a fictional worked example. Publication date: September 2026.

Evidence maintained with the project

Attach current vendor documentation and support matrices for the selected source, destination, guest, application, and tools; customer architecture and control requirements; current commercial terms; and the actual test results. Record versions and retrieval/review dates. These project-specific sources govern executable procedures.

For Synaptix, obtain the current approved Product Capability Matrix and deployment documentation. Product commitments and support must be confirmed for the actual deployment. The fictional example is instructional and makes no measured customer or product-performance claim.