Rescuing a Failed Symantec EDR Migration to Azure VMware Solution for a Global Mining Organisation

The Challenge

An ASX-listed global mining organisation was operating a large-scale Symantec Endpoint Detection and Response (EDR) environment supporting approximately 50,000 endpoints across its global operations. The platform ran on two physical Symantec EDR appliances hosted in a US-based data centre, configured in a primary and backup model.

The data centre was scheduled for permanent shutdown within three months. The Symantec EDR platform had to be migrated to Azure before that deadline - with no extension available.

Symantec EDR virtual appliances require VMware-based infrastructure and cannot run directly on native Azure IaaS compute. This made the migration non-trivial: the target environment had to be Azure VMware Solution (AVS) - VMware infrastructure running within Azure - rather than a straightforward lift to Azure virtual machines. Each Symantec EDR virtual appliance supports approximately 10,000 endpoints, so the 50,000-endpoint environment required a minimum of five appliances; the final target architecture used seven, for additional capacity headroom, resilience, and migration flexibility. The migration also had to include the supporting Microsoft SQL Server infrastructure holding endpoint and EDR-related data.

A migration pilot had already been attempted by the organisation's global MSP delivery team. The pilot did not succeed. With the data centre closure deadline fixed and the initial approach having failed, Pyneora's principal architect was engaged directly by the vendor as a Symantec EDR specialist to diagnose the failure, design a validated target architecture, rerun the pilot, and deliver the full migration within the remaining data centre exit window. The engagement involved a global delivery team spanning Perth, Singapore, the United States, India, and Sydney.

The Approach

Diagnosing the Failure

The revised pilot initially failed in a similar way to the previous attempt. After investigation and technical analysis, the root cause was identified as certificate corruption within the migrated Symantec EDR appliance. During migration, the appliance certificate became invalid, which prevented the EDR virtual appliance from initialising and operating correctly in the Azure VMware Solution environment. This failure mode was not immediately visible - appliances migrated successfully at the infrastructure layer but failed to start at the application layer, making diagnosis non-trivial.

Target Architecture Design

Before establishing Pyneora under its current brand, our principal architect designed the full target migration architecture for the Symantec EDR environment on Azure VMware Solution - seven EDR virtual appliances sized for 50,000 endpoints, with the supporting Microsoft SQL Server backend included in scope. The architecture accounted for the VMware appliance dependency, the capacity requirements per appliance, and the resilience model needed for an enterprise endpoint security platform at this scale.

Root Cause Resolution

Once the certificate corruption failure mode was identified, the migration process was updated so that each migrated EDR virtual appliance was issued a new certificate immediately after migration - before the appliance was brought online. This resolved the startup failure consistently across all appliances and established a repeatable remediation step for the rest of the migration sequence.

Delivery Within the Hard Deadline

With the revised architecture and corrected migration process validated, our principal architect executed the full migration across all seven EDR virtual appliances within the three-month data centre exit window. The organisation exited the Houston data centre on schedule, with endpoint visibility and threat detection capability maintained throughout the migration.

Metric	Outcome
Endpoints protected	~50,000 across global operations
Physical appliances replaced	2 physical → 7 virtual (Azure VMware Solution)
Delivery timeline	Within three-month data centre exit deadline
Prior migration attempts	Previous pilot had not succeeded - delivered on revised approach
Endpoint visibility during migration	Maintained throughout - no gap in threat detection coverage

Why Azure VMware Solution?

Symantec EDR virtual appliances require a VMware hypervisor layer; native Azure IaaS (Hyper-V based) is not a compatible target. Azure VMware Solution provides VMware vSphere infrastructure running within Azure datacentres, making it the correct target platform for organisations that need to move VMware-dependent workloads to Azure without re-platforming.

Why Seven Appliances?

Five appliances would have covered the minimum requirement. Seven provided capacity headroom for endpoint growth, appliance maintenance windows, and migration flexibility - allowing traffic to be shifted between appliances during the migration sequence without gaps in coverage.

Lessons for Australian Businesses

Enterprise security platform migrations carry a category of risk that infrastructure migrations do not: if the security platform is unavailable during the migration, endpoint visibility gaps open. For a 50,000-endpoint environment, even a short gap in EDR coverage represents significant exposure. The right approach sequences the migration so coverage is maintained throughout - migrating appliances incrementally, validating each before proceeding, and only decommissioning source appliances once the target environment is confirmed operational.

This engagement reflects the depth of platform-specific expertise and architectural discipline that Pyneora's principal architect brings to complex security migrations - delivering at enterprise scale, within hard deadlines, across global delivery teams, and under the pressure of a failed prior attempt.

A Cloud Infrastructure Rationalisation engagement brings that same expertise and discipline to de-risking complex security migrations for your organisation.

Client details have been anonymised. Technical specifications, endpoint counts, and delivery timeline reflect the actual engagement. This engagement was delivered by Pyneora's principal architect prior to the establishment of Pyneora as an independent advisory practice.