Migration Needs More Than a Cutover Date

A migration is ready for acceptance when the business workflow, data, recovery path, and operating ownership are validated. The VM starting is only one of those checks.

Picture the moment after a cutover. The application starts. Health checks pass. Traffic reaches the new environment. The project plan has a green milestone.

Then comes the less comfortable question: who owns the first production alert?

The answer should already be in the plan. Not in the memory of the engineer who stayed late. Not in a temporary chat channel that will go quiet next week.

The first article in this series covered what should move. This one covers what needs to be true before a migration can reasonably be called done.

Start with the Work the Business Needs to Do

Infrastructure tests answer useful questions. Is the VM reachable? Is the process running? Can the load balancer see a healthy target?

They do not tell you whether an order completes, a report reconciles, or a scheduled job reaches its downstream system.

For each business service, agree who signs off and what they will test. Record the expected result, the evidence, and the threshold for stopping. If acceptance means something different to the infrastructure team and the application owner, resolve that before the migration window.

Move Dependencies, Not Convenient Server Batches

A server list makes it easy to divide work into batches. An application can make that division unsafe.

Its database may be elsewhere. Authentication may still depend on an on-premises directory. A nightly transfer may rely on a firewall rule nobody has changed in years.

Define move groups around relationships that must remain intact. Then sequence them into waves that account for business calendars, engineering capacity, connectivity, and recovery. Google’s migration-wave guidance treats architecture, business considerations, and operations as planning inputs, not just workload counts.

In AAIC’s selective application-modernization engagement, the starting point was a B2B software environment with 120 VMware workloads. The treatment was not “containerize everything.” It combined compatible VM destinations, selected containers and managed services, and retained systems.

That distinction matters. A migration wave should not quietly become an application rewrite without a separate owner, scope, and acceptance plan.

Rollback Changes When the Data Changes

Before the destination takes writes, returning traffic to the source can be relatively straightforward. Afterward, the old database may no longer represent the business.

“We can point DNS back” is not a complete answer when transactions have happened on the other side.

Record the last safe rollback point, the person who can call it, and the data-reconciliation procedure. Decide when forward recovery is the safer option. Test the restore path and the time it takes; replication status alone does not prove recoverability.

AWS’s cutover guidance explicitly separates rollback without new data from recovery after data has changed. That is a design question to settle in rehearsal, not on an incident bridge.

Give Operations Something They Can Actually Accept

A handover document is useful only if the receiving team can use it.

Before acceptance, walk through the service with the people who will support it. Verify production access through the approved process. Trigger a safe test alert. Find the relevant logs. Follow a runbook. Confirm how to reach the application owner and the vendor when needed.

Include backup and restore evidence, patch ownership, deployment and rollback procedures, incident escalation, and cost ownership. A hybrid service also needs a clear boundary between cloud support, retained infrastructure, application engineering, and external providers.

AAIC’s Day-2 hybrid-operations case study covers that operating problem. Our CloudOps, DevOps, SRE, and FinOps work sits alongside OpsRabbit-assisted investigations. OpsRabbit helps assemble and correlate evidence from connected systems. Engineers review the findings and own the operational response.

Watch OpsRabbit in action: From Alert to Root Cause in Minutes.

More dashboards cannot compensate for an unresolved owner.

Watch the First Real Business Cycle

The service may behave normally during the first hour and fail during the first backup, batch run, or reporting cycle. Choose the stabilization period around the workload, not a convenient date in the project plan.

AWS’s post-cutover guidance calls for stakeholder-aligned monitoring and a workload-appropriate support period. A service with an infrequent business cycle needs deliberate validation of that cycle.

Keep the migration team available under an agreed handover arrangement. Record open defects, residual risks, and who accepts them. Use the findings to improve the next wave rather than treating every migration as a fresh experiment.

Decommission by Evidence, Not by Calendar

Source retirement deserves its own approval. Confirm that rollback obligations are closed, dependencies have been removed, records are retained appropriately, and backup access still works.

Then verify that infrastructure and licensing costs actually stop where the business case expected them to. Otherwise, a technically successful move can leave two operating environments and one disappointing financial result.

The VMware Workload Decision Guide brings these checks into a reusable register. It connects the original workload decision to acceptance and ongoing ownership.

The cutover date still matters. It is simply not the finish line by itself.