Sophos XG vs XGS: differences, EOL and migration

The XGS series has been the successor to the XG series since 2021. Comparing old and new hardware is no longer just about performance. The last XG Series models reached End of Life on 31 March 2025; some older models had reached EOL earlier. In addition, SFOS 21.0 and later firmware lines no longer support XG and SG Series hardware.

The real question is therefore no longer Is XGS worth it?, but How do you plan the move from XG cleanly, without overlooking routing, VPN, Central Firewall Reporting or remote sites?

Short answer

XG and XGS both run Sophos Firewall OS, but they are no longer equivalent platforms.

• Lifecycle: XG: End of Life. XGS: actively supported hardware platform.
• Firmware: XG: no SFOS version from 21.0 onwards. XGS: current SFOS lines, including 22.0.
• Performance: XG: older platform with less headroom for modern inspection. XGS: Xstream architecture; usable acceleration depends on the model, firmware and traffic path.
• Operations: XG: migration and support boundary. XGS: standard platform for new hardware projects.
• Planning: XG: replacement required. XGS: sizing, port mapping and licence transfer must be settled before cutover.

An XG should therefore no longer be treated as a normal firewall model, but as a legacy platform that needs replacing. For licence and lifecycle questions, also see the Sophos Product Lifecycle calendar.

What End of Life means in firewall operations

For firewall hardware, End of Life is not a formal entry in a table. A firewall sits at the network edge, terminates VPNs, filters web and application traffic, protects published services and often contains sensitive configurations. If this platform is no longer maintained, a real operational risk is created.

For a production XG, these points are especially critical:

• New SFOS firmware lines can no longer be used.
• Sophos warns that software updates stop shortly after EOL; vendor support and hardware replacement therefore can no longer be planned reliably.
• New functions such as current VPN, logging, Health Check or security features arrive on supported platforms.
• Licences, RMA, replacement devices and support cases become harder to plan.
• Audits and cyber insurance can critically assess continued operation of an EOL firewall.

This is particularly critical for firewalls with active Remote Access VPN, site-to-site VPN, WAF, TLS Inspection, Web Protection, published servers or broadly reachable WebAdmin. In such environments, continued operation of an XG should only be treated as a temporary transition with a documented migration plan.

The three most important differences

XG and XGS may look similar from the outside depending on the model, but technically and operationally they differ significantly.

• Lifecycle and firmware: XG hardware is End of Life. SFOS 21.0, 21.5 and 22.0 no longer support XG and SG Series hardware. XGS is the supported hardware platform for current SFOS versions.
• Architecture and performance: XGS uses the Xstream architecture and model-dependent acceleration. This gives more headroom for current security functions, VPN, TLS Inspection, IPS, Web Protection and routing. The data sheet for the specific model remains authoritative for acceleration.
• Migration and operations: Moving to XGS is a migration project. Backup compatibility, port mapping, licence status, HA, SD-WAN, Central Firewall Reporting, RED, Access Points and ZTNA gateways must be checked.

Architecture: Xstream instead of the old XG platform

The XGS series was built for the Xstream architecture. This matters especially when protection functions are enabled. Accelerated traffic paths and available resources differ across desktop, 1U and 2U models, however; the series name alone says nothing about throughput. Many older XG installations were also sized when there was less TLS Inspection, cloud traffic, SD-WAN and Remote Access load.

Depending on the model, an XGS Appliance provides more headroom for:

• IPS, Web Protection and Application Control.
• TLS Inspection and larger certificate/CA rollouts.
• IPsec VPN, SSL VPN, SD-WAN and multiple WAN uplinks.
• More simultaneous users, sessions and rules.
• New SFOS functions that are no longer available on XG at all.

Not every data path automatically becomes faster just because an XGS Appliance is installed. Incorrect sizing, models that are too small, poorly planned TLS Inspection or unclear VPN architecture can also slow down a new firewall. For choosing the right target model, the Sophos Firewall Sizing Guide is more important than a simple one-to-one model comparison.

When an XG should be replaced

An XG replacement should not only be planned when a firmware upgrade is blocked or a hardware defect already creates pressure. A migration project is due at the latest when these signals appear:

• The firewall should be updated to SFOS 21.0, 21.5, 22.0 or later.
• Remote Access VPN, WAF, publicly reachable services or several site-to-site VPNs exist.
• Support, audit, RMA or licence renewal can no longer be handled cleanly.
• The existing XG is at its limit under IPS, Web Protection, TLS Inspection or VPN load.
• RED, Access Points, SD-WAN, Central Firewall Reporting or ZTNA depend on the existing firewall.
• An HA cluster, port redesign or provider change is already planned.

If an XG is still running in production, first document a current backup, the Secure Storage Master Key and the firmware version in use. The process is described in more detail in Create or restore a Sophos Firewall backup.

Plan migration from XG to XGS

When migrating from XG to XGS, do not only choose the supposedly closest model. A short inventory before the maintenance window is more useful:

• Which WAN, LAN and DMZ ports are actually used?
• Are there HA, VLAN stacks, RED, SD-WAN or VPN special cases?
• Which security functions are active today and which should be enabled additionally in the future?
• Which IPsec, SSL VPN, Sophos Connect or ZTNA scenarios are in production?
• Are Central Firewall Reporting, management through Sophos Fusion or SD-WAN Connection Groups used?
• Are Access Points or SD-RED devices bound to this firewall?
• Are there static routes, alias IP addresses, DNAT rules or WAF publications that must be reachable immediately after the change?
• Should the target platform be hardware again, or a virtual or cloud appliance?

Decide the firmware path before taking the backup

The XG can’t be upgraded to SFOS 21.0 or 22.0. Sophos therefore distinguishes restores by the version on the source XG; on the target XGS Appliance, Backup-Restore Assistant requires SFOS 20.0 MR2 or later:

• With 19.5 MR4 or any 20.0 version, take the backup directly and map interfaces during restore with Backup-Restore Assistant.
• With 19.5 MR3 or earlier, migration is possible, but the assistant doesn’t appear. Sophos recommends first upgrading the XG to 19.5 MR4 or 20.0 MR2 and later, provided that intermediate step is still supported and operationally acceptable.

The new XGS Appliance’s Setup Assistant upgrades the target to the latest version it offers. If the move also introduces SFOS 22, review the Sophos Firewall firmware update guide before the maintenance window. In particular, a legacy Remote Access IPsec configuration blocks upgrades to 22.0 MR1 and later, while legacy CLI VLAN tagging on bridge interfaces blocks 22.0 MR2 and later; backups containing the latter can’t be restored to 22.0 GA or later either. SFOS 22 may also require additional disk space and changes policy-based IPsec VPN behaviour.

Avanet recommendation: Combine the hardware move and a major firmware change in one window only after these checks pass. Otherwise, a failure leaves unnecessary doubt about whether the backup, port mapping or firmware change caused it.

Backup-Restore Assistant and port mapping

Port mapping and Backup-Restore Assistant must be planned for the exact source and target appliances: port names and counts, Flexi Port modules, wireless variants and target models do not always match one-to-one. XG Flexi Port modules are incompatible with XGS and must be replaced with compatible XGS modules.

In practice, prepare a port table before the restore:

• Port1 to Port1 for LAN: check VLANs, DHCP and DNS.
• Port2 to Port2 for WAN: check the gateway, alias IP and NAT.
• Port3 to Port4 for DMZ: check Firewall Rules, WAF and DNAT.
• Flexi Port to a new module: check the uplink, trunk and module compatibility.

The assistant only shows physical ports. VLAN and alias interfaces follow their parent interface; LAGs and bridges are recreated from their mapped physical members. Unmapped bound interfaces can become pseudo ports. Check not only the port number, but also zone, IP assignment, Link Mode, parent interface and membership.

Wireless models have additional restore limits. When restoring an XG Wireless or Gen.1 XGS Wireless backup to a Gen.2 XGS Wireless model, Sophos specifies WPA2 or later, no TKIP, no wireless interfaces in physical bridges and no more than eight unique SSIDs across LocalWiFi0 and LocalWiFi1, among other restrictions. Restoring to a model without integrated wireless requires the wireless networks to be removed before taking the backup. Treat that change as a separate, verified configuration step rather than improvising it during cutover.

If the WAN MAC address changes, upstream routers or provider CPEs may still hold old ARP entries. For such symptoms, see Fix Sophos Firewall ARP problems after migration.

Treat HA separately

An XG HA cluster is not simply replaced by restoring to two new XGS Appliances. If an HA backup is restored to a new XGS Appliance without HA, the restore doesn’t recreate the HA configuration; it must be configured manually. Identical models, firmware version, licences, HA port, monitoring, passphrase, role change and test window therefore belong in a separate procedure, for example with Set up Sophos Firewall High Availability.

Follow up Sophos Fusion, reporting, SD-WAN and ZTNA

After the restore, the new XGS Appliance is not automatically integrated into every Sophos Fusion function in the same way. Depending on the environment, you must:

• register the new firewall in Sophos Fusion,
• check Firewall Management and Central Firewall Reporting,
• assign the separate Central Firewall Reporting licence and its data to the replacement device; local XG reports aren’t transferred,
• for SD-WAN Connection Groups, first delete the rules and tunnels created by Sophos Fusion with the Central_ prefix on the XGS Appliance, then add it to the group,
• switch ZTNA gateways to the new firewall,
• test SD-RED and Access Point assignment; if the XG remains connected in parallel, delete its SD-RED configuration and accept the Access Points on the XGS Appliance,
• recheck notifications, backups and scheduled reports.

For reporting setups, also see Enable Central Firewall Reporting. For operational evidence after migration, Test a Sophos Firewall rule with Log Viewer and Packet Capture and Analyse dropped packets on Sophos Firewall are more useful than a simple ping test.

Typical errors in XG-to-XGS migrations

Target model too small

A seemingly suitable successor model can be too small if more users, more VPNs, more TLS Inspection, more Web Protection or more bandwidth have been added since the original XG purchase. Therefore, do not only compare XG model against XGS model, but consider real load, active protection functions and growth.

Port mapping checked only roughly

If LAN, WAN, DMZ, VLAN trunks, HA ports or provider connections are plugged differently, a successful restore is not enough. After the restore, interface zones, gateways, SD-WAN routes, NAT rules, WAF rules and Firewall Rules must be checked deliberately.

Old firmware or old backup state

A very old backup state increases the risk that interface mapping, certificates, VPNs or special configurations migrate unexpectedly. Before the change, bring the old firewall to a suitable state where still sensible and supported, and create a fresh backup.

Downstream systems forgotten

Many migrations fail not because of the restore, but because of dependent systems: monitoring, Syslog, SIEM, backup emails, VPN clients, provider ARP, DNS, DHCP, RED, Access Points or Sophos Fusion. These points belong in the checklist, not in troubleshooting after the cutover.

Checklist before the change

• Current firmware of the XG and target firmware of the XGS Appliance documented.
• Restore compatibility of the exact source and target models checked in the Sophos tool.
• Current backup created and restore password stored securely.
• Current and, if applicable, previous Secure Storage Master Key plus backup password available securely and separately.
• Port mapping prepared for WAN, LAN, DMZ, VLAN trunks and HA.
• XG Flexi Ports replaced by compatible XGS modules; wireless restrictions checked.
• Licence transfer, Sophos Fusion registration and support status checked.
• For SFOS 22: legacy IPsec, CLI VLAN tagging, disk space and policy-based IPsec VPNs checked.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS and routing prepared as a test list.
• RED, Access Points, ZTNA, Central Firewall Reporting and monitoring considered.
• Rollback plan with old device, cabling plan and maintenance window defined.
• Contacts for provider, DNS, monitoring and applications reachable.

Rollback with a clear abort threshold

Keep the old XG unchanged, powered off or physically isolated, and available with a labelled cabling plan until acceptance. Before cutover, define a time and measurable abort criteria, such as an unreachable WAN gateway, a failed critical DNAT publication, or a business-critical VPN tunnel that remains down after the reserved diagnostic period.

For rollback, isolate the XGS Appliance, return cabling to the XG according to the plan, and only then power on the XG. Recheck WAN, routing, VPN and published services. Changes made by users or administrators during the XGS Appliance test period aren’t automatically present on the old XG; record and assess them after rollback. Do not reset or dispose of the XG until the XGS Appliance has been accepted as stable, backed up and documented.

Checks after migration

After switching over, do not only check whether the internet works. A clean migration is only complete when the most important operating functions have been validated:

• Check dashboard, licence status, Sophos Fusion registration and backup email.
• Test WAN gateway, alias IP addresses, NAT and published services.
• Check site-to-site VPN, Remote Access VPN and Sophos Connect profiles.
• Check SD-WAN routes, static routes and Route Precedence.
• Test Firewall Rules with logging.
• Spot-check IPS, Web Protection, TLS Inspection and Application Control.
• Check RED and Access Point connections.
• Test Syslog, Central Firewall Reporting, notifications and monitoring.
• Take the old XG out of operation only after a stable operating phase.

If individual destinations are not reachable directly after migration, work systematically with Log Viewer, Packet Capture and routing checks. For basic diagnosis, Use Sophos Firewall Packet Capture in WebAdmin and Change Sophos Firewall Route Precedence safely help.

FAQ