Sophos XG vs XGS: differences, EOL and migration

The XGS series has been the successor to the XG series since 2021. The original comparison between old and new hardware is no longer only a performance question today. Sophos XG hardware has been End of Life since 31 March 2025. 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 Reporting or remote sites?

Short answer

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

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.
• Security updates, Hotfixes and vendor support are limited or no longer available.
• 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 with dedicated acceleration functions. This gives more headroom for current security functions, VPN, TLS Inspection, IPS, Web Protection and routing.
• Migration and operations: Moving to XGS is a migration project. Backup compatibility, port mapping, licence status, HA, SD-WAN, Central 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. In daily operation, this is not only a marketing term, but is especially relevant when protection functions are enabled. Many older XG installations were originally sized when there was less TLS Inspection, less cloud traffic, less SD-WAN and less Remote Access load.

Depending on the model, an XGS 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 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 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, Sophos Central Management 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?

Backup-Restore Assistant and port mapping

The Migration Center for XG-to-XGS migrations is the most important external reference for port mapping and Backup-Restore Assistant. This matters because port names, port count, Flexi Port modules, wireless models and target models do not always match one-to-one.

In practice, prepare a port table before the restore:

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 devices. HA must be deliberately replanned: identical models, firmware version, licences, HA port, monitoring, passphrase, role change and test window. The details belong in HA planning, for example with Set up Sophos Firewall High Availability.

Follow up Central, reporting, SD-WAN and ZTNA

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

• register the new firewall in Sophos Central,
• check Firewall Management and Central Reporting,
• check Central Firewall Reporting licence and data assignment,
• reassign SD-WAN Connection Groups,
• switch ZTNA gateways to the new firewall,
• test RED and Access Point assignment,
• 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 Central. 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 documented.
• Current backup created and restore password stored securely.
• Secure Storage Master Key known and documented.
• Port mapping prepared for WAN, LAN, DMZ, VLAN trunks and HA.
• Licence transfer, Central registration and support status checked.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS and routing prepared as a test list.
• RED, Access Points, ZTNA, Central Reporting and monitoring considered.
• Rollback plan with old device, cabling plan and maintenance window defined.
• Contacts for provider, DNS, monitoring and applications reachable.

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, Central 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 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