Migrate SVA Log Collectors to Sophos XDR Data Collectors

When moving to the enhanced Sophos XDR solution, Sophos provisions a new XDR Data Collector configuration for eligible Sophos Security Virtual Appliance (SVA) log collectors. This neither installs nor activates the VM automatically in your environment. You must deploy the replacement, switch the Syslog path and verify fresh events. If both collectors use the same IP address, the old collector must not be running when the new one starts.

The XDR Data Collector is a virtual Syslog receiver on premises or in AWS, Azure or GCP. It forwards ingested logs to Sophos XDR. A direct API integration does not require this Syslog receiver. The integration runbook explains Data Ingest, Response Actions and these connection types.

If you already use Sophos Next-Gen SIEM, Sophos recommends replacing existing SVA Syslog collectors with XDR Data Collectors to make use of the full data retention supported by the SIEM product. Existing API integrations do not need to be reconfigured for this Syslog collector replacement. This does not imply a particular retention period or SIEM retention entitlement for all XDR tenants; the retention terms applicable to your own SIEM product remain authoritative.

Checked on 11 October 2026: the migration guide dated 1 October 2026 supplements the September rollout. The earlier EAP documentation path records version provenance; it does not promise that every tenant already has the feature. First check the tenant-specific upgrade status and the collector actually offered under Security Operations > Integrations > Data Collectors. This runbook covers Syslog cutover and a specific on-premises deployment on vSphere. It explains cloud addressing, but creation of the respective cloud resources is outside the vSphere procedure.

Inventory existing workloads and settings that are not migrated

For each old SVA collector, record the platform, name, hostname, static network settings or DHCP lease, every sending source and its Syslog destination, port and protocol. Also note the data format, event-type selection, domain and protocol exclusions, passthrough settings and required credentials. Document the last verifiable incoming data from each source so that, after cutover, you can distinguish an inactive stream from a fault.

The collector name, hostname or its derived value, static IP address, subnet mask, gateway and DNS settings or the DHCP setting, and Syslog port/protocol mappings are transferred automatically. Original source ports are retained and mapped to the standard Syslog ports UDP/514 or TCP/601. The platform type determines the new cloud or on-premises collector.

The following are not transferred automatically:

• NDR integrations: NDR does not use a Syslog forwarding path. Only the Syslog portion of a mixed-use SVA is migrated; an NDR-only SVA does not receive an XDR Data Collector for this purpose.
• Event-type filters and domain and protocol exclusion lists.
• SVA-specific Syslog format and passthrough settings.
• Integration credentials.
• Investigation Consoles, Nessus Scanner and other VM types outside SVA log collectors.
• Physical hardware appliances: these are not automatically migrated to virtual collectors.

Explicitly check which filters and formats the new integration still needs and which configuration options its connector provides. Missing filters can ingest more data than intended; an incorrect format can cause logs to be processed only as generic events. Do not copy credentials from tickets or old screenshots; supply them afresh through the designated secret-management process.

If NDR runs on the same SVA, a Syslog cutover must not inadvertently shut down the sensor. Reusing the same IP requires shutting down the old SVA and therefore interrupts its NDR workload too. Plan NDR operation separately, or choose a different IP for the new Syslog collector so that the SVA can continue running NDR. The NDR operations runbook covers this workload; provisioning a Syslog replacement is not an NDR migration.

Choose the addressing strategy before downloading

The destination address determines whether both VMs can run simultaneously and whether sources need to be changed.

For a static address with the same IP, plan a short switchover: shut down the old SVA, then start the new VM. Sources keep their destination. This does not guarantee a lossless handover; whether events survive the interruption also depends on the source system’s buffering and transport.

For a gradual migration, set the new static IP before downloading the ISO. For example, the old collector uses 192.0.2.10 and the new one 192.0.2.20. Do not use these documentation addresses in production. Instead, select an unused address in the correct network and check the subnet, gateway, DNS and reachability from the source networks. A new IP simplifies rollback and allows sources to be switched individually, but requires updated destination and firewall rules.

For DHCP with reuse of the old IP, document the old and new VM MAC addresses, the existing IP reservation and the current lease state before cutover. Then change or create the reservation so that the new VM MAC address receives the old IP, following the documented reservation and lease procedure for your DHCP platform. Next shut down the old SVA, and only then boot the new collector. Check its actual lease and assigned IP before accepting the data flow. A reservation does not prevent an old VM that is still running from using the same address.

For cloud collectors, the address always changes. In an AWS CloudFormation stack, Outputs provides CTPxCollectorDnsName. This is the Network Load Balancer DNS name and is preferable to a hard-coded IP for Syslog sources. In Azure, check the VM network-interface address in the Azure portal; in GCP, check the internal address under Compute Engine > VM instances. DHCP addresses can be found in the lease table using the new MAC address, or under Data Collectors. Do not confuse this destination for sources with the regional Sophos uplink addresses.

Prepare the network path and collector resources

Uploads from the collector to Sophos XDR use mTLS with TLS 1.3 and outbound TCP/443. This does not mean that no inbound ports are required: your Syslog sources must reach the collector on their configured port and protocol. Standard destinations are UDP/514 and TCP/601; also compare migrated port mappings with the previous configuration. Do not create blanket Internet access to the Syslog receiver.

Allow the regional uplink, DNS and time services

The following collector uplink destinations are a snapshot checked on 11 October 2026. The US1/US2/US3/EU1/EU2 mapping comes from the XDR collector configuration, not an assumed equivalence with an AWS Central region. Use only the region actually assigned. The existing Sophos IP set for incoming API calls at the third-party provider is a different allowlist.

If your firewall requires IP-based permissions, the following destination addresses belong to this snapshot. Do not combine regions:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Before a production change, compare the region and destination values with the current tenant configuration and the collector safelist maintained by the operations owner. Any discrepancy requires a reviewed change, not a precautionary broader permission. The technical endpoint spelling secureworks.com remains unchanged.

The collector also needs UDP and TCP/53 to the DNS servers entered during provisioning. Time synchronisation requires UDP/123 to the selected NTP servers. Without a custom NTP setting, non-AWS collectors use 0.pool.ntp.org through 3.pool.ntp.org; the AWS default is 169.254.169.123. With local NTP, traffic between collector and time server must be permitted in both directions. For the on-premises collector, these NTP values serve bootstrap; after connection, the XDR backend channel handles time synchronisation. According to the platform guide, Windows domain controllers are not an NTP destination for this non-domain host.

A forward web proxy can be configured through Host Proxy. The collector overview excludes statically configured authenticated proxies, whereas the on-premises guide also shows URL syntax containing a username and password. These statements do not agree. Do not plan a production authenticated-proxy path without clarified Sophos approval, and do not work around the conflict by embedding credentials in the ISO. With TLS inspection, the specific mTLS uplink must work without MITM interception. Limit any exception to the required collector connections.

Do not size the on-premises VM using old SVA values

The new on-premises VM requires 4 vCPUs at a minimum of 2 GHz, 8 GB RAM, a 20 GB system disk and a 200 GB data disk. The platform guide lists vSphere ESXi 6.7 or later, Hyper-V 8.0 on Windows Server 2016 or later, and Nutanix 6.8.x or later as recommended environments. The VM must expose x86-64-v2 CPU features; an unsuitable CPU compatibility mask can prevent startup.

The figure of up to 200,000 EPS is an upper limit for appropriately configured cloud and on-premises collectors, not a throughput guarantee for these minimum resources. Size for event count, size and peak load, and monitor actual data flow. Do not install third-party tools or additional applications on the collector. Updates are automatic, usually every 24 hours when connectivity is healthy.

Deploy the preprovisioned on-premises collector on vSphere

For an existing migration, use its associated configuration under Security Operations > Integrations > Data Collectors. Compare the name, network settings and Syslog mappings with the old SVA. Download the ISO containing the collector configuration and the OVA for the VM. They belong together; an ISO from another collector would provision the wrong state. Restrict access to configuration files.

If the configuration is missing, first check the exclusions and network errors in the next section. To deliberately create a replacement manually, the interface offers Actions > Add Collector > On-Premises > Next. Enter the name and hostname, optionally a description, Host Proxy and NTP, and either DHCP or complete static network settings, then use Create Collector. This is not a reason to create an uncontrolled duplicate alongside an existing migration.

Deploy on vSphere as follows:

1. In the vSphere Web Console, open Virtual Machines > Create / Register VM and select Deploy a virtual machine from an OVF or OVA file.
2. Assign a unique VM name, such as sophos-xdr-collector, and select the downloaded OVA. The name is your choice; it should distinguish the VM from the old SVA in the hypervisor.
3. Select a datastore with at least 220 GB free for the two disks. Check network mapping and disk configuration, review the summary and complete with Finish. Leave the VM powered off for now.
4. Upload the matching configuration ISO under Storage > Datastore Browser.
5. Open Edit Settings for the VM. Change the CD-ROM from Client Device to Datastore ISO File, select the uploaded ISO and save. Before first startup, verify that the ISO is actually attached and the VM can reach the correct source network.
6. If reusing the same IP, shut down the old SVA now. Only then start the new VM. With a new IP, the old SVA may remain running; switch sources individually afterwards.
7. Under Security Operations > Integrations > Data Collectors, wait for the new collector to show Ready. Only then detach the ISO. Ready does not yet confirm correct ingestion from every source.

For Hyper-V, Sophos provides a VHD package instead of an OVA; for Nutanix, it provides QCOW2 files. The second data disk and the ISO attached at first boot are still required. Do not apply the vSphere click sequence to these platforms. Likewise, deploy cloud collectors using their platform-specific resources, not as an OVA in vSphere.

Switch sources and validate data flow

If the destination address changes, update all affected devices and applications to the new collector IP or DNS name. Change only the destination, not the port, protocol or log format without verification: these mappings should transfer from the SVA. A source previously using UDP/514 continues to use UDP/514 for this migration. Switching transport to TCP is a separate change requiring source-system validation.

With different IPs, switch a manageable source first. Generate a harmless event captured by the connector and record the source, event type and time with time zone. Find it in XDR through the data or query path offered for that integration. Evidence must show the correct tenant, source, timestamp and event format. Allow for expected connector delays; a test event need not create a Case or Detection.

Switch the remaining sources only after this check. For each source, compare the last events before cutover with the first afterwards. Identical intervals or event rates are not expected for every source; what matters is actual activity and the absence of unexplained gaps. Avoid unplanned simultaneous delivery of the same stream to both collectors, which can create duplicates.

The existing SVA can continue working during planning. Historical SVA data already ingested remains queryable in XDR; the replacement does not need to resend it. This does not create a new unlimited-retention promise. The new collector’s 200 GB spool buffers logs when the uplink is slow or temporarily interrupted. It is neither a substitute for checking the source nor a guarantee against arbitrarily long outages.

Operational acceptance is reached only when every expected source supplies current, correctly attributed data, filters and exclusions have been deliberately reviewed, DNS, time services and uplink work, and NDR continues separately where applicable. Document the cutover time and observation period. Preserve the old SVA and its configuration for possible rollback until then; only afterwards decide how to handle its remaining workloads and safe decommissioning.

Troubleshoot and roll back without an IP conflict

No new collector exists: Hardware appliances, NDR-only SVAs and non-SVA VMs are not migrated automatically. For an actively used Syslog SVA, check that the port and protocol are configured and static network settings are complete. Missing gateway or DNS values can prevent migration. Correct invalid network configuration in Fusion and discuss rerunning migration with Support, or create an explicitly planned manual collector. Do not enter placeholder addresses just to make a form accept them.

New VM does not start: Check ISO attachment, the second disk, RAM, vCPUs and the x86-64-v2 features exposed to the VM. Do not install repair or monitoring software on the collector.

Collector remains offline: First check its actual assigned IP or lease, gateway, DNS and bootstrap time services. Then examine firewall/proxy logs for the regional TCP/443 uplink. An open outbound port alone does not prove a successful mTLS channel. When reusing the same IP, also ensure the old SVA is really off.

Collector is Ready but a source is missing: Check the source destination, route and inbound Syslog port. Compare port mapping and format with the old integration. An upstream log forwarder must retain the expected integration format; otherwise data may arrive as generic events instead of the expected schema. Prove the data path first, then look for a Detection.

Treat static addresses and DHCP reservations separately during rollback:

• Static, same IP: Shut down the new VM, then start the old SVA with its preserved static configuration. Sources keep their previous destination. Verify that the old SVA actually uses this IP and receives and forwards fresh Syslog events. Never power on both VMs with this address.
• DHCP reservation, same IP: First shut down the new VM. Then assign the reservation for the old IP back to the documented old SVA MAC address and handle the lease state according to your DHCP platform’s documented procedure. No universal lease-deletion command is assumed here. Only then start the old SVA, check its actual lease and IP, and demonstrate ingestion and forwarding with a fresh Syslog event. Sources keep their previous destination, so simply starting the SVA does not prove a working rollback. Never power on both VMs with this address.
• Different IP or DNS destination: Restore the documented source destinations and, if necessary, associated network rules to the old collector. Use a fresh event to verify that the old SVA is receiving and forwarding again. Decommission the new collector only after checking every mapping.

Rollback is accepted only when the old SVA demonstrably holds the intended destination address and fresh Syslog events are again ingested and forwarded.

Rollback works only while the old SVA remains available with its configuration preserved. It does not reverse the vendor-side product upgrade or guarantee recovery of undelivered events. Sophos announces a later end of support for SVA log collectors but gives no specific date in the migration version reviewed here. After migration, new log collector instances must be created as XDR Data Collectors; the old SVA is therefore a limited fallback for an existing deployment, not a long-term new-installation strategy.

If the cause remains unclear, collect collector and tenant identities, platform, sanitised network settings, affected source, exact time windows, status and error message. Follow Open a Sophos support ticket for escalation. Secrets, configuration ISOs and unsanitised log data do not belong in publicly accessible tickets or screenshots.