Proving Every App Still Works After a VMware Migration

You prove an application still works after a VMware migration by testing what its users and connected systems do with it, not by checking that the virtual machine booted. Record a baseline of every business-critical journey on VMware before anything moves, then run the identical tests after cutover on the target and compare the two runs screen by screen. The comparison, with screenshots and a defect log, is the evidence for the go or no-go decision.

Testing is the part of a VMware exit plan that is easiest to squeeze. The deadlines push the other way: licence-included pay-as-you-go Azure VMware Solution (AVS) deployments must move to portable VCF by 31 October 2026, and vSphere 8 reaches end of general support on 11 October 2027. This post sets out a testing method that keeps pace with those dates. It sits under our main guide, Leaving VMware After Broadcom, and the testing cost belongs in your renewal versus Azure cost model.

Why isn't "the VM booted" enough?

Infrastructure checks answer infrastructure questions. Is the VM running? Does it answer a ping? Is the service started? Those checks matter, but they say nothing about whether a user can raise an invoice, approve an order or run the month-end report.

A migration changes the things around the VM. Azure Migrate's network discovery for VMware and NSX (preview, August 2026) shows how much sits there: subnets, VLANs, NSX segments, port groups, load balancers, and firewall and NAT policies. Any of those can change during a move, and the VM will still report healthy.

The route changes how much moves. AVS runs the same vSphere, vSAN and NSX stack in Azure, so the application sees the least change, although its network location and connections still move. A rehost to Azure VMs swaps the platform underneath. A move to containers is a rebuild, and Microsoft documents behaviour differences that matter on that route: Windows nodes on AKS do not preserve client source IP and have a fixed four-minute TCP timeout. An IP allow-list at a partner, or a long-running connection, can fail there and nowhere else. On-premises, Harvester's VM import add-on shuts down the source VM and converts its disks before creating the new one, so the imported VM is a new machine in practice.

Our post on choosing a route for each workload covers those routes in depth. Whichever you choose, the test method is the same.

What should the baseline cover?

The baseline is a recorded run of your tests on VMware, before migration, for every business-critical journey. It becomes the reference that the post-cutover run is judged against.

Start with the journeys, not the servers. For each application, ask its owner which tasks would stop the business if they broke: posting a sales order, receiving stock, running payroll, producing a customer statement. Then add the journeys that run without a person, such as overnight imports, interfaces and scheduled reports.

Azure Migrate helps you find what you might miss. Its agentless dependency analysis covers up to 3,000 servers per appliance and shows which servers talk to which. Automatic application discovery (preview, May 2026) groups servers into applications. Dependencies you did not know about become integration checks.

Each journey needs five things written down:

• the steps a user or system takes
• the test data and accounts it uses
• the expected result at each step
• the integrations it touches
• the application version under test

Run the baseline more than once. Two clean runs tell you which differences are natural, such as dates, reference numbers and timestamps, so they are not flagged as failures later. Then freeze the application: no releases between baseline and cutover, or a fresh baseline after any release that does happen. Otherwise you cannot tell whether a difference came from the migration or from the change.

AI agents make this practical across a whole estate. They run the regression tests, then open the application and work through each journey through the user interface, clicking, entering data and moving between screens, recording a screenshot and a log line at each step. Our Agentic Software Delivery capability describes how we run agents in a delivery process.

How do you re-run the tests after cutover?

You run the same tests, with the same data and accounts, against the target. Nothing in the test changes except the address it points at. If the test needs editing to pass, that edit is itself a finding.

We recommend two post-migration runs per wave. The first is a rehearsal: migrate a copy, run the full baseline against it, fix what breaks, and repeat. For VMware, Microsoft recommends Azure Migrate agentless replication, which uses vSphere snapshots and Changed Block Tracking. The second run happens in the cutover window itself, on the real target, before users return.

The target shapes what to watch for:

1. On AVS, focus on the network. Check name resolution, firewall rules between AVS and the rest of Azure, and connectivity back to on-premises systems that have not moved yet.
2. On Azure VMs, also check anything tied to the old hardware or hypervisor, such as licence keys bound to a machine identity, agents and drivers.
3. On containers, treat the run as acceptance testing of a new build. Expect more differences, and check source-IP-dependent rules and long-lived connections explicitly.

How do you compare results with screenshot evidence?

The comparison takes the baseline run and the post-cutover run for each journey and lines them up step by step. Each step has a result (pass or fail against the expected value) and a pair of screenshots, before and after.

Agents flag every difference and sort it into one of three groups:

The pairing matters more than the pass mark. A screen that "passes" can still show a blank field that used to hold a value from another system. A person reviewing the side-by-side screenshots spots that in seconds. A person reading a log line saying "step 7: pass" does not.

Which integration checks matter?

Integrations are where a move is most likely to break something, because each one depends on addresses and rules that live outside the VM. Check each integration in both directions, and check the data, not just the connection.

• APIs called by the application, and APIs it exposes to others
• file transfers, shared folders and EDI exchanges
• email sending, through whichever relay the application uses
• database links and reporting connections
• single sign-on and directory lookups
• printing, label and document output
• backup jobs and monitoring agents
• partner allow-lists that name your old public IP addresses

Some integrations run rarely. A monthly batch, a quarter-end extract or a year-end process will not run during a weekend cutover. List them, schedule a check at their first run after go-live, and keep the old environment available until they have passed.

The best integration test runs through the user interface. Our anonymised release-testing client has agents check what appears on screen at each step, including data that arrives through integrations. A journey that shows the right order status from a connected system has proved the integration end to end.

How do Azure DevOps defects get raised and verified?

Every functional difference becomes a work item in Azure DevOps, so fixes are tracked in the same place as the rest of the delivery work. The flow mirrors the bug verification we run for a client today:

1. The agent raises the bug with the journey, the step, the expected and actual result, and both screenshots attached.
2. The team triages it and links it to the cause: a firewall rule, a DNS record, a configuration value or the application itself.
3. Once a fix is deployed, the agent repeats the original steps on the target and records what it sees.
4. The work item gets the steps, the new screenshots and the result.
5. A person closes the item, or reopens it with the evidence attached.

A bug is only reported as fixed once an agent has repeated the original steps and seen the correct result. That rule stops "resolved" tickets from reaching the go or no-go meeting unchecked.

The method step by step

Cutover checklist

What goes in the evidence pack?

The evidence pack is the document the go or no-go meeting reads. It should let someone who was not in the cutover room see what was tested, what was found and what is still open.

A complete pack contains the journey register and test scope, the baseline results, and the post-cutover results with the difference report. It includes screenshot pairs for every flagged difference, the integration check results, and the Azure DevOps defect list with each item's status. It closes with the accepted exceptions (each with an owner and a fix date), the rollback position, and the sign-offs.

Keep the pack after go-live. It records the state of each application on the day it moved, which helps the managed service team and any later audit.

Where do people stay in control?

Agents do the repetitive work: running tests, capturing screenshots, comparing runs, raising and re-checking defects. People make every decision that carries risk.

• Application owners approve the journey register, because they know what matters.
• A person reviews each flagged difference and decides whether it is expected, cosmetic or a defect.
• People close or reopen Azure DevOps items; agents only add evidence.
• The change board makes the go or no-go call from the pack.
• A named person owns the rollback decision and can make it at any point in the window.

We also recommend that agents have test access only, with no rights to change production configuration. Fixes go through your normal change process.

What AI testing work has Veriland already done?

Our VMware exit case study covers the migration side: an oil and gas company in Scotland left its own VMware infrastructure by three routes. The testing capability this method relies on is published separately. In our anonymised release-testing case study, agents test every release of a client's own applications before it ships. They run the regression suite, test the affected journeys through the user interface with screenshots, and verify every Azure DevOps bug fix in the running system. The client's team makes each release decision, and 15+ testing roles are no longer needed.

That work is release testing, not migration. The mechanics carry across unchanged: a baseline, a re-run, a comparison with screenshot evidence, and defects verified in Azure DevOps before a person closes them. Our VMware exit service builds that testing into every migration wave.