Would Your VMware Migration Cutover Survive an Audit?

Picture an auditor, six months after your migration, asking you to walk through wave 14. Who approved it? What else did it touch? What changed during the window, and who signed off when it was done? If the answers live in a bridge call, a chat thread, and an engineer's memory, the cutover went fine and the record still fails. The fix is to treat evidence as part of the cutover itself. Decide what an auditor will ask before the window opens, capture each answer as the work happens, and keep it all in one record per wave. VMware migration automation makes that practical at scale, because the plan, the approvals, the status, and the audit trail live in the same place.

The risk is real. According to Uptime Institute's 2025 outage analysis, nearly 40% of organizations had a major outage caused by human error over the past three years, and 85% of those incidents came from staff not following procedures or from flawed procedures. Uptime's 2026 report found that failure to follow established procedures is still the leading driver. A cutover is a procedure-heavy night, and the record is how you prove the procedure was followed.

Regulators are asking for that proof. In the EU, DORA requires financial entities to make sure every change to ICT systems is recorded, tested, assessed, approved, implemented, and verified in a controlled manner. And with vSphere 8 general support ending on October 11, 2027, many programs will run their busiest waves under the closest scrutiny.

What will an auditor ask about your cutover?

A cutover is auditable when someone outside the project can reconstruct it from the record alone. Expect five questions.

• What moved: which virtual machines, in which wave, from which source to which destination.
• Why it was safe to move: the dependencies, owners, and readiness checks behind the decision.
• Who approved it: named approvers, with timestamps, before the window opened.
• Who did the work: the delivery team that executed each step, and the tools they used.
• What happened: validation results, any deviations, and how each one was resolved.

Where does cutover evidence usually go missing?

Most gaps open during the window, when the team is focused on the move and nobody is focused on the record.

• Approvals given verbally on a bridge call, with nothing tied to the change.
• Unplanned changes made to save the window and never reviewed afterward.
• A fallback plan that exists in a runbook nobody attached to the change record.
• Validation marked complete without the acceptance criteria it was checked against.

Uptime's 2025 data, as reported by Network World, lists configuration and change management failure as the most common cause of IT and networking outages, cited in 50% of cases. A cutover concentrates that risk into a few hours.

What do DORA and NIST expect from a migration change record?

The frameworks use different words. They agree on the basics.

• DORA Article 9(4)(e) requires documented change management policies, procedures, and controls, approved by appropriate lines of management. DORA has applied across the EU since January 17, 2025.
• The DORA technical standard on ICT risk management, Article 17, adds fall-back procedures, independence of approval functions, and dedicated handling for emergency changes, which must be documented and approved even after they are made.
• NIST SP 800-53, control CM-3, calls for reviewing and approving proposed changes, documenting change decisions, implementing approved changes, retaining change records, and monitoring change activity.

Your auditor will map these to your own control set, such as SOX IT general controls or SOC 2 change management criteria. Here's how they translate to a cutover.

What does an audit-ready wave look like, hour by hour?

Frameworks and tables only go so far. The record is built on a real night, by tired people, under time pressure. So here's one wave from start to finish. It's a composite example, the kind of wave that shows up in almost every large VMware program, and it follows the evidence as it's created.

• Two weeks out, wave 14 is locked. Forty virtual machines, three applications, one Saturday night window. The plan rests on a dependency map that caught something a spreadsheet would have missed: the order management application shares a database server with a reporting tool that was scheduled for wave 16. ReadyAI flagged the conflict and recommended moving both together. The program lead approved the change, and the decision went into the record with her name on it. That kind of catch is why we treat dependency work as the foundation of every wave, as we laid out in our guide to VMware dependency mapping.

• The same week, each application owner confirms the window. Owners get timed communications, pick from available slots through self-service scheduling, and attest that their acceptance tests are ready. None of this happens on email threads that an auditor can't follow. We've written about why this coordination is where most programs actually slip in The Complete Guide to VMware Migration Coordination, and it matters just as much for evidence. An owner's attestation is a record. A reply-all is not.

• The day before, the fallback plan is attached to the change record for the wave. It names the trigger: validation fails on any of the three applications and can't be fixed inside 45 minutes. It names who can call it: the delivery lead, with the application owner informed. It lists the steps the delivery team will follow, and it confirms the source virtual machines stay powered off and untouched until validation passes. That is the fall-back procedure DORA's technical standard asks for, written so someone who wasn't there can check it.

• At 10:00 p.m., the go/no-go call happens on the bridge. In most programs, this is the first evidence to disappear. Here, the decision is recorded with who made it, what time, and which readiness checks it rested on. The delivery team starts the transfer, and the migration tool, Nutanix Move in this case, does the mechanical work. The split between the tool that moves virtual machines and the program that governs the move is one we covered in our Enterprise VMware Migration Automation Guide for 2026. On a night like this, you feel it. The mover reports progress. The program records everything around it.

• At 1:30 a.m., something goes off plan, because something always does. A migrated virtual machine needs a firewall rule the plan didn't include. An engineer adds it to keep the window on track. That's an emergency change, and it's exactly what DORA's technical standard says must be documented and approved even after it's made. So it's logged in the window: what changed, why, and who approved it, with a review scheduled before the team signs off. Six months from now, this is the line an auditor will look for first.

• At 3:15 a.m., validation fails on the reporting tool. The team works the issue for 45 minutes, then the trigger is met. The delivery lead calls the fallback for that application only. Because the source virtual machines were kept intact, the team returns the reporting tool to its original state, confirms it's healthy, and records the trigger, the decision, the time, and the outcome. The other two applications pass validation. In most cases, this is how a well-run fallback looks: narrow, documented, and decided by the person the plan named.

• By 6:00 a.m., the wave closes. Validation results are signed against the acceptance criteria. The emergency change review is complete. Status for wave 14 rolls up into the program view next to every other wave, which is how large programs stay visible without another status call, as we described in The IT Leader's Guide to Automating VMware Migration Waves. The reporting tool gets rescheduled into wave 15, with its own record and its own approvals.

• The work doesn't stop at sunrise. The weeks after cutover bring validation in production, drift control, and the handoff to operations, all covered in our VMware post-migration operations guide. But the evidence for wave 14 is already complete.

• Now go back to that auditor. Who approved the wave? Recorded, with names and times. What else did it touch? The dependency decision is on record from two weeks out. What changed during the window? One emergency change, logged and reviewed. Was there a fallback, and did it work? Yes, triggered by a written condition, called by a named lead, with the outcome recorded. Nobody needs to remember anything.

Notice what made that possible. Nobody worked harder. The difference is where the evidence went.

That's the role of the ReadyWorks platform and VirtualReady. VirtualReady handles assessment, planning, wave orchestration, and migration status across migration tools, with Nutanix Move supported today. ReadyAI analyzes the estate, recommends, and plans. A named delivery team executes, whether that's a services partner, ReadyWorks when engaged to deliver, or your own engineers, with your sign-off at every phase.

Every action on the platform is logged, explainable, and covered by a tamper-evident audit trail, with what changed, who approved it, what it touched, and the outcome on record.

Find the Gaps Before Your Auditor Does

Every cutover produces evidence. The question is whether it lands in one record or scatters across inboxes and memories. With vSphere 8 general support ending in October 2027, the time to decide how your record works is before the busiest waves begin.

Start by seeing where your estate stands. Map your journey on our ten steps page and choose a VMware exit as your first program. You get your first five steps, your first governed actions, who does the work, and how long it takes, in a PDF you can share with leadership and audit. Or talk to someone who has done this.

Frequently Asked Questions

Would a VMware migration cutover survive an audit?

It will if someone outside the project can reconstruct it from the record alone: what moved, why it was safe, who approved it, who did the work, and what happened. If any answer depends on interviewing someone, the record has a gap.

What evidence should a VMware cutover record include?

Named approvers with timestamps, the readiness checks behind the go/no-go call, who executed each step and with which tool, every deviation and emergency change, validation results against acceptance criteria, and the documented fallback plan.

How should emergency changes during a cutover be documented?

Log them during the window with what changed, why, and who approved it. Then complete an after-the-fact review. DORA's technical standard on ICT risk management requires emergency changes to be documented and approved even after they are made.

What does DORA require for ICT change management?

DORA Article 9 requires that changes to ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner, under documented policies and procedures. It has applied since January 17, 2025.

Does an audit trail make a migration compliant?

No. An audit trail is evidence. Your auditor decides whether your controls meet the framework you are held to. A complete, tamper-evident record makes that review faster and leaves fewer open questions.

Who executes the cutover when ReadyAI builds the plan?

A named delivery team: a services partner, ReadyWorks when engaged to deliver, or your own engineers. ReadyAI analyzes, recommends, and plans. Your team or partner executes, with your sign-off at every phase.