New Sophos Support Phone Numbers in Effect July 1st, 2023

Status of the migration tool

Dear Devs,

which is the status of the migration tool?

Other vendors are already supporting XG to their brand while in Sophos we cannot even migrate all settings from UTM9 to XG.

I think that v18 is mature enough for most of the UTM 9 users so a tool is needed, guys, to migrate complex installations to XG.

We would like to have an update.


  • Hi  

    Please take a look at ChrisMcCormack's post here for context.

    • The UTM to XG Migration Assistant is available to Sophos Partners
    • Customers/End-Users should reach out to their Sophos Partner / Rep for more info

    Note: Sophos Partners can access this blog post that provides more information

    Director, Global Community & Digital Support

    Are you a Sophos Partner? | Product Documentation@SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the 'Verify Answer' button.
    The Award-winning Home of Sophos Support Videos! - Visit Sophos Techvids
  • Flo,

    my question is more about the status of the tool in terms of features that are still not covered by the tool.

    We expect to have a tool that convert everything from UTM 9 to XG.

    Certain complex installations, starting from the scratch is almost impossible, as customers have refined their configuration that is impossible to reproduce it.


  • Hello FloSupport and Luk,

    give me some time and I think I will be able to tell you if the migration tool is able to migrate the configuration from UTM v9.701 to v18 EAP3-Refresh1. 

    Alternatively, I will report any errors in the migration tool, if I will be able to identify them.



  • Hi Luciano,

    (congrats for winning the TOP COMMUNITY USER xg firewall for Q4 :)

    I can unterstand the migration-pain for customers and wish for an 'one-click all-inclusive happy-outcome' Tool.

    I do also remember some UTM Migrations (v8-v9.1-v9.2 ?), when the Web Filtering Subsystem was changed and we had to re-configure the Web Policy everywhere.

    We normally ended up discussing the current needs along future projects with customers and could sell additionally services almost all the time. E.g. regular Policy reviews or UTM Maintenance.

    Nobody has to start from scratch and even UTM 9.7 Backup Migrations to XGv18 EAP still work (woth tricks) to assist with huge Objectlists.

    XML API can assist as well with complex configurations. And we try to migrate all SSL VPN Users to Sophos Connect as well.

    What do you mean exactly with

    lferrara said:
    have refined their configuration that is impossible to reproduce it

    Nobody wants simply pump a UTM config in a XG without additional reconfigurations or adjustments! E.g. Zones, User-Auth, Web Filter,...and with XGv18 (DPI, SSLx, NAT,...)


    Regards Steven

  • Hi Alda,


    Hint: just remove 9701 from unencrypted UTM Backups and SMA still works (producing 17.5-compatibel XG configs).




  • Hi Steven

    dos the migration migrate all the configurations? Like ipsec, WAF, Certificates and so on?

    On the partner portal, there is a pdf that shows which components cannot be migrated. The list of objects that cannot be migrated is long.

    Maybe they released a new version?

  • Hi Luciano,

    we still use SMAOS from April 2019 Partnerportal Post

    • SW-SMAOS_17.0.0_SMA_2-1818.iso, Checksum : b5dc34c1b34eb8ecbc4a5770c0ca46c3 or
    • Update  SW-SMAOS_17.0.0_SMA_2.SFW-1818.gpg, Checksum : 747c19f9e56688fec09658f8760dddff

    WAF: no (afaik) and IPsec: yes


    Site-to-Site VPN

    • IPsec: Connections; remote gateways; policies; local RSA key; Advanced
    • SSL: Settings; Advanced
    • Certificate Management: Certificates; certificate authority

    Remote Access

    • PPTP: Global
    • L2TP over IPsec: Global
    • IPsec: Connections
    • Advanced





  • Hello all,

    as I mentioned, I spent some time testing migration from v9.701 to v18 EAP3- Refresh1 and here are my findings:

    - the latest officially supported version is v9.605-1. If you want to migrate v9.700-5 or v9.701-6, you have to replace v9.700-5 / 9.701-6 in the .abf file with the latest supported version v9.605-1. Thanks   for letting me know how to fix the problem with supported backup version! 

    - Firewall rules where the source or destination is object  (User Network) are not migrated and there is no record or notification anywhere in the documentation / migration log. Please see to the first picture below for example rule. In my tests, the configuration migration "disappeared" a total of 7 firewall rules without a single record of why this happened. I know that users objects ( or group ) are not migrated as part of the migration, but the secondary consequence is that there are also dropped firewall rules in which user objects are used. Without any warning!

    - The first migrated firewall rule ID has the highest number and the last migrated firewall rule has the lowest number ID of rules, which is in my opinion totally illogical. Of course, is true that the ID rules in UTM9 and XG have different functions and meanings. However, for UTM9 administrators who migrate to XG, it will be very confusing and this error (in my opinion) will not make it easier to work in the new XG environment.

    - The network object Internet is erroneously migrated. The problem is, I think very well document by the following two pictures ( again below ) and by picture of the Internet object. The result of a bad migration firewall rule is the target zone Any, although the target zone have to be WAN zone ( I think ) !. Unfortunately, as you know the Any zone in the migrated rule means any zone within the XG configuration (WAN, LAN, DMZ, WiFi, VPN, etc.). In my opinion a very critical error in migration!

    A possible solution to this problem could be a "translation table" at the beginning of the whole migration. Thus, this migration table give the administrator the ability to define which interface from the UTM9 configuration will be migrated to what target zone in the XG Firewall itself.

     For example:

    Eth0       ->           LAN

    Eth1       ->           WAN

    Eth2       ->           DMZ

     Another significant benefit of such a translation table would be to automatically add the appropriate zones to the migrated firewall rules. Now, after migration, all migrated firewall rules do not have either a source or destination zone assigned. The consequence is the need to additionally edit all firewall rules and define the appropriate source and target zones, which in the case of several hundred or more firewall rules may be somewhat exhaustive.

    - Obviously, NAT rules are not migrated, this is obviously the result of removing NAT rules from the complex firewall rules in v17.5


    In my opinion, the current version of the migration tool is not applicable to v17.5 and certainly not to v18. However, in the first half of October last year, I received the following response to my previous notice regarding the quality of the migration tool:

    Hi alda,

    I've received feedback from the Migration team:

    They appreciated your analysis and feedback and will reference it as they continue to work on improving and enhancing the migration experience. They are currently working on the next version of the tool and will provide more info as it becomes available.


    So my question is, when will be released new migration tool for migration from v9.x to v18? 



  • Comprehensive test, Alda.

    So the tool is not still very useful if you have/use more than "normal" configuration.

  • Hi Alda,


    thank you for sharing the test results. But honestly we never used the Internet Object ( at WAN, introduced in UTM 7.5!) for more than SSL VPN or Guest-Wifi as Destination and avoided User Network Objects at all cost. UTM is imo not an Identity-based Firewall!

    So try to adjust these quite uncommon configurations and enjoy the rest of the Tool :)

    You can generate an Public IPv4 Object with for example.




  • Hello ,

    on the contrary, I see a really big advantage in using the "Internet" object in UTM v9. Therefore, if you look at the description of this object for IPv4 or IPv6, here is "" Any "network, bound to interfaces with default gateway". Etc. all networks available ONLY on the Internet BEHIND default gateway or Uplink Interfaces. Because, compared to the "Any" network object (which you most likely use), the "Internet" object does not include any internal networks and possibly DMZ networks defined behind the firewall internally as a subset of the relevant IPv4 / IPv6 networks.

    This is a fundamental difference between "Any" and "Internet" objects. From my point of view, my firewall rule set (when using the "Internet" object) is logically much more secure and also necessarily with less firewall rules, because I do not have to deal with potential security collisions when using the "Any" object. Furthermore, the "Internet" object is essentially a WAN zone definition in UTM v9, as defined as a zone object in the XG Firewall!
    So, for the above reasons, I see very good (above) reasons why, when defining firewall rules in UTM v9 for communication from any internal network in the direction to the Internet, use "Internet" as the target network in the Internet.

    And therefore (again for the above reasons) I claim and Sophos confirmed that the migration of the "Internet" object is wrong in the current version of the migration tool, as they themselves have verified in their internal tests.



  • I use Internet object too on my installation and I taught my customers to use Internet for everything that is not LAN or inside their network.

    Any is very dangerous and must be used carefully. I fully agree with Alda.

    The tool must be optimized to migrate the full configuration, even WAF.

    It is not impossible, as there is code behind and it can be done.

  • I use Internet object too on my installation and I taught my customers to use Internet for everything that is not LAN or inside their network.

    Any is very dangerous and must be used carefully. I fully agree with Alda.

    The tool must be optimized to migrate the full configuration, even WAF.

    It is not impossible, as there is code behind and it can be done.

No Data