Use Azure Migrate Discovery to Find PHP Workloads in AVS

Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.

When a runtime vulnerability is announced, an existing migration inventory can be a useful starting point for finding affected systems. Azure Migrate software discovery can help narrow an Azure VMware Solution (AVS) estate, but discovery results are not a complete vulnerability verdict. Coverage, guest access and the way the application is packaged all matter.

Check what the inventory actually covers

Identify the Azure Migrate project, discovery method and appliance that collected the data. Confirm that the relevant vCenter and target VMs are included through a supported connectivity and permissions path. Review the support matrix for the selected discovery experience; “the VM appears in the inventory” does not prove guest software discovery succeeded.

Record the latest successful collection time and any credential or connectivity errors. A powered-off guest, inaccessible operating system or excluded folder can leave gaps. Keep AVS platform services and vendor-managed appliances separate from workloads you administer, because their support and patch processes differ.

Search broadly enough to find candidates

Look for PHP packages/runtimes and web-server software in the software inventory. The documented web-app discovery experience focuses on supported application types such as ASP.NET; it is not a general PHP application scanner. Treat matching names as candidates for investigation. A web server may serve static content, use another runtime, or host several applications with different requirements.

Also record likely false negatives: portable installations, application-bundled runtimes, custom paths and containers. Guest package inventory alone can miss the runtime inside an image. A reassuring host package list is not evidence that every container running on that host is unaffected.

Validate the finding at the workload boundary

• Confirm which application uses PHP and who owns it.
• Identify the actual runtime version and packaging source, not just the web-server banner.
• For containers, inspect the running image and the relevant package/runtime within an approved diagnostic process.
• Compare the exact build and vendor advisory, including backported security fixes.

Do not declare a system vulnerable solely because an upstream version string is old. Distribution packages and appliance builds can carry vendor fixes without adopting the upstream version number. Conversely, an inventory with no match should be reported with its coverage limits, not as an unconditional clean bill of health.

Turn inventory into a small action list

For each confirmed candidate, record owner, runtime/build, exposure, advisory applicability, proposed action and recovery route. A patch, rebuild, vendor upgrade or retirement may be appropriate, but discovery alone does not authorize shutting down a business service.

After an approved change, verify the runtime actually serving the application and repeat the relevant assessment. Preserve evidence of the scan scope and time. The useful result is a defensible shortlist with verified dispositions, not a claim that a migration tool replaced guest/container security assessment. This pattern applies to other runtimes too: inventory provides direction; workload-level verification supplies the conclusion.

References

• Microsoft: software inventory discovery with Azure Migrate
• Microsoft: VMware discovery support matrix
• PHP: supported branches and security support