Microsoft's October 23, 2026 modernization guidance highlights a networking check that belongs in an existing VM's maintenance plan: an eligible machine can encounter Microsoft Azure Network Adapter, or MANA, without changing its VM size. The guidance is a readiness reminder, not an announcement that every existing VM has moved to new hardware. Microsoft's review.
For an operations team, the useful question is whether the deployed guest and application are ready for the hardware they may encounter after a placement change.
Identify the Machines Where the Check Applies
Microsoft's existing-series documentation focuses on VMs using Accelerated Networking. It says no MANA-specific action is required when Accelerated Networking is not enabled.
My proposed inventory would record the exact VM series, guest image, operating-system version, networking configuration, and application owner. Separate observed settings from assumptions copied from an infrastructure template.
Use that inventory to choose the relevant review path. Do not enable or disable Accelerated Networking merely to make the fleet look consistent; that would be a separate configuration decision.
For machines serving shared infrastructure, identify the dependent applications before planning any interruption.
A Maintenance Event Can Matter Without a Resize
Microsoft documents that eligible existing VMs can land on MANA-capable hardware after a stop-deallocate-start operation or a standard Azure maintenance event. Placement timing varies by series; an earliest eligibility date is not a promise that a particular VM has transitioned. Placement behavior.
I would add guest-network readiness to the review already performed before an approved maintenance window. The change record should explain how connectivity and application behavior will be checked afterward.
Keep this review distinct from a retirement migration. Hardware eligibility, guest compatibility, and a VM family's support lifecycle are separate facts that may all matter to the same workload.
Do not schedule a production deallocation simply to discover what hardware appears next. Use an approved test environment and a defined recovery procedure when an exercise is needed.
Validate the Guest Image, Including Older Hardware Support
The documentation calls for a MANA-compatible operating system and the relevant Linux kernel or Windows drivers. For eligible machines that can use either hardware generation, it also says existing mlx4 and mlx5 support must remain present. Compatibility steps.
My first image review would compare the deployed guest with the team's supported image baseline. Include custom images, where a historical optimization may have removed drivers that seemed unnecessary at the time.
Record the image version and the evidence used to approve it. Updating an image definition does not establish that all running instances now use the corrected guest configuration.
Bring the image maintainer and application owner into the same acceptance decision. Network reachability alone may not reveal an application's sensitivity to connection churn or latency.
Give Specialized Networking Its Own Review
Microsoft points network virtual appliances and DPDK-based applications to workload-specific MANA guidance. Specialized workload requirements.
I would flag those machines rather than put them through a generic web-server checklist. Confirm the supported software combination with the appropriate platform or appliance owner.
Define the relevant validation before the test: expected flows, routing behavior, connection handling, and the application's own success criteria. Use a controlled workload that can reveal the behavior the service actually depends on.
Keep packet captures and diagnostic output scoped and access-controlled. An investigation record should not become an unnecessary collection of application data.
Retain Application-Level Acceptance
My recommended handover would include baseline observations, post-maintenance checks, escalation contacts, and a recovery decision owner.
Exercise representative application paths during an approved validation window. Confirm dependencies and monitoring as well as basic login or a successful health check.
If results differ, preserve the evidence and use the support path appropriate to the workload. Do not interpret a MANA-capable placement as a guaranteed performance upgrade for an unchanged application.
Practical Cloud Engineer Takeaway
Inventory the actual series, guest, and Accelerated Networking state.
Include placement changes in maintenance readiness reviews.
Verify deployed OS and driver compatibility.
Retain support for the hardware generations the VM can encounter.
Review NVAs and DPDK workloads through their specialized guidance.
Who Should Care?
Azure infrastructure engineers, image maintainers, and application or appliance owners running existing VM series with Accelerated Networking.
Bottom Line
An unchanged VM size is not sufficient evidence that its guest will always see the same network hardware. A useful readiness plan connects eligible placement, a supported image, and application-level acceptance.
No VM was stopped, deallocated, resized, updated, or tested for this article. No networking configuration was changed.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments