EN 
15.04.2026 Anastázie WELCOME IN MY WORLD

This website is originally written in the Czech language. Most content is machine (AI) translated into English. The translation may not be exact and may contain errors.

Tento článek si můžete zobrazit v originální české verzi. You can view this article in the original Czech version.
FortiGate přechod na nový hardware a migrace konfigurace

FortiGate Migration to New Hardware and Configuration Conversion

| Petr Bouška - Samuraj |
This article describes my experience with replacing Fortinet FortiGate devices that are reaching end of support with new ones. Obviously, we want to transfer the current configuration as simply as possible and achieve minimal downtime during the switchover. We will use the FortiConverter service for configuration migration. The situation is somewhat more complex because the solution is built as a High Availability FGCP cluster with two nodes. Less significant is the use of VDOMs. FortiGate is currently running on FortiOS 7.4.11. The final device switchover went (after prior preparation) very well with only a five-minute outage.
displayed: 1 287x (682 CZ, 605 EN) | Comments [1]

Situation Description

In general, this involves replacing Fortinet FortiGate FG-300E with FortiGate FG-200G.

Documentation

Current Solution

Because support for the current FortiGate devices is ending, it is necessary to purchase new ones and transfer the configuration to them. We are replacing two HW boxes FortiGate FG-300E, which will soon be Out of Support, with new FortiGate FG-200G. Newer generations typically offer higher performance, so if requirements have not increased, it is possible to choose a lower model range.

HW Appliances are configured as an FGCP HA cluster (FortiGate Cluster Protocol High Availability) and use VDOMs (Virtual Domains). They are currently running on FortiOS 7.4.11.

Configuration Migration Method

My original idea was to restore the current configuration on the new device, and that would be it. However, in that case problems may arise, mainly due to differences between HW models.

The recommended solution is to use the FortiConverter service. It also supports migration from other vendors' firewalls. In the case of FortiGate-to-FortiGate conversion, it enables migration from older versions and between different hardware. It handles, for example, interface mapping. Under certain conditions, we can use it for free.

General Device Replacement Procedure

  • connect both new devices, perform basic configuration and registration
  • save (back up) the configuration from one of the existing FortiGates and convert (migrate) it using FortiConverter
  • restore the converted configuration on one new device
  • connect the second new device to the cluster, configuration synchronization will occur
  • fine-tune configuration details
  • shut down the original devices, reconnect the network cables, power on the new devices

Connection and Basic Configuration

On both new boxes, we perform basic configuration that enables connection to the web/SSH management over the network. We mount the devices in the rack, ideally close to the existing ones, so we can simply reconnect the network cables during the swap. We connect the MGMT interface to the network and interconnect the Heartbeat Interfaces of both boxes.

Preparing Credentials

We prepare basic information for both the existing and new devices.

  • name, IP address for management, model, serial number
  • admin account password (temporary/permanent)
  • virtual IP address for management

If we want to connect both the existing and new devices (Management) to the administration network simultaneously, we must use different IP addresses. Here we have a cluster, so a virtual IP and MAC address is used for management. For direct access to individual cluster members, we use In-band management (and therefore additional IP addresses). This is described in the article FortiGate High Availability cluster and Virtual Domains (VDOM).

Connecting to the Device

For management, we can primarily use the Console Port or the MGMT Ethernet port. For initial setup, we can connect the MGMT port to a network with DHCP to obtain an IP address. Or we can use the preconfigured address 192.168.1.99/24. We can then connect to the GUI at https://192.168.1.99.

After logging in, it is first necessary to set a password, followed by the mandatory step of FortiCare registration. We are unable to change any settings, for example to configure internet access.

Fortinet FortiGate FG-200G

In some cases, it may therefore be more convenient (or necessary) to connect via the console and perform the initial configuration in the command line (CLI). Included in the box is a nice white console cable to USB, which worked immediately (emulates a serial COM port). I also tried the classic blue Cisco console cable. We can use PuTTY with the standard 9600-8-N-1 settings.

Fortinet USB Console Cable

Initial CLI Configuration

We log in as admin with no password. Setting a password is enforced.

FortiGate-200G login: admin
Password: 
Verifying password...

You are forced to change your password. Please input a new password.
New Password: 
Confirm Password: 
Verifying password...
Welcome!

We set the IP address on the MGMT interface.

Note: When attempting to set the address, I found that a LAN interface is created with the IP address 192.168.100.99/24. If this subnet conflicts with our management network, it must first be changed or removed.

config system interface
    edit "lan"
        set ip 192.168.2.100 255.255.255.0
    next
    edit "mgmt"
        set ip 192.168.100.223 255.255.255.0
    next
end

Setting the gateway for MGMT.

config router static
    edit 1
        set gateway 192.168.100.1
        set device "mgmt"
    next
end

Setting the hostname for better identification.

config system global
    set hostname FW1n
end

DNS is preconfigured, but I had to change the protocol to get it working.

config system dns
    unset protocol
end

Device Registration

Using a web browser, we log in to the GUI and are required to complete FortiCare registration and accept the terms.

Register FortiGate with FortiCare

The new FortiGate then immediately appears in the list of our products on FortiCloud.

FortiOS Upgrade

I think it is better to have the same firmware version on the new box as on the existing one. Both new FortiGates must certainly have the same version to form a cluster. The devices were delivered with FortiOS 7.4.8, so I upgraded to FortiOS 7.4.11. I did this via CLI, although we could complete the initial wizard and upgrade via the GUI.

Note: I did not test whether this step can be performed right at the beginning or whether the device must be registered first.

FW1n # execute restore image management-station ?
Image-ID    Version
07006000FIMG0035306006  v7.06 MR6-GA-M P6 b3652 (upgrade)
07006000FIMG0035306005  v7.06 MR6-GA-M P5 b3651 (upgrade)
07006000FIMG0035306004  v7.06 MR6-GA-F P4 b3596 (upgrade)
07004000FIMG0035304011  v7.04 MR4-GA-M P11 b2878 (upgrade)
07004000FIMG0035304010  v7.04 MR4-GA-M P10 b2867 (upgrade)
07004000FIMG0035304009  v7.04 MR4-GA-M P9 b2829 (upgrade)
07002000FIMG0035302013  v7.02 MR2-GA-M P13 b6687 (downgrade)
07002000FIMG0035302012  v7.02 MR2-GA-M P12 b6663 (downgrade)
07002000FIMG0035302011  v7.02 MR2-GA-M P11 b6561 (downgrade)
07002000FIMG0035302008  v7.02 MR2-GA-M P8 b6397 (downgrade)

FW1n # execute restore image management-station 07004000FIMG0035304011
Please wait...

Getting image 07004000FIMG0035304011 from Management station...
########################################################################
This operation will replace the current firmware version!
Do you want to continue? (y/n)y

Verifying the signature of the firmware image.
Warning: Upgrading to an image with Mature maturity notation.

Please wait for system to restart.

Transferring the Existing Configuration to the New Device

Fortinet offers a (one-time) cloud-based migration service FortiConverter Service. Simply upload the existing firewall configuration and after some time download the converted result.

Alternatively, we can use the software tool FortiConverter Tool, which is intended for service providers. It allows an unlimited number of conversions and is available as part of an annual subscription.

FortiConverter License

To use the FortiConverter service, we need a license. For converting configuration between FortiGate devices, it can be obtained for free. The Enterprise Protection bundle includes a full FortiConverter license (Comparing Bundles).

Configuration Migration in FortiGate GUI

Since FortiOS 7.4, it is possible to transfer the configuration from an older FortiGate device to a new one directly from the FortiGate graphical user interface during FortiGate Setup. Both FortiGate devices must be registered under the same FortiCare account and have available communication to FortiConverter servers. The target FortiGate must have a valid FortiConverter license.

On the source device, it is necessary to enable Allow FortiConverter to obtain config file once. On the target device, a wizard is run that creates a ticket on the FortiConverter Portal (without needing to connect to the portal directly). The conversion takes some time (typically stated as 1 business day). The migrated configuration is then applied (restored) directly from the FortiGate GUI.

The migration can also be performed later, as this step is offered at every login. Simply skip it now using the Later button and complete the wizard.

Note: The dialog kept showing that I had no license and I was unable to click Convert. I contacted support, which confirmed it should work — at most, synchronization with FortiGuard had not occurred. Nevertheless, this feature still did not work for me. In the end, I used the FortiConverter portal (the process is very similar, so the integration into the FortiGate GUI does not add much benefit).

FortiGate Setup - Migrate Config with FortiConverter - license

FortiConverter Service Portal

Configuration migration is performed by creating a ticket at service.forticonverter.com, where we log in with our FortiCloud account. Either under Tickets - Create New Ticket or under Devices in the Action column next to the device and Create Ticket.

Note: The documentation states that this is a one-time conversion service. Within 12 months of the service contract registration date, only one service ticket can be created. However, this may not apply to the full license in the Enterprise Bundle, as additional migrations are offered to me.

Ticket Creation Wizard

  1. Ticket Basics - first, select the target device and enter contact details
  2. Device - in the next step, select the source device manufacturer, upload the configuration, and specify the target FortiOS version
  3. Interface Mapping - a more complex step involving the mapping of interfaces of all possible types; most are prepared automatically, but all source physical interfaces must be mapped; unused interfaces can be marked as Do not migrate
  4. Review Interface Migration - shows how the interfaces look after configuration migration; settings can be adjusted
  5. Select Management Interface - select the management interface for the target device and set the IP address
  6. Comment - special requirements can be added in the comment field
  7. Submit Ticket - the complete configuration is displayed; clicking Create Ticket submits the request
FortiConverter Service Portal - Create Ticket - Interface Mapping

The input for the migration is of course our configuration, which we send to Fortinet. It typically contains passwords and other sensitive information. We may consider whether to mask them in the input configuration and add them back afterwards.

Note: Fortinet states that conversion typically takes 1 to 2 days. My conversion was completed in an hour and fifteen minutes.

Downloading the Converted Configuration File

Once the request has been processed, we will receive an email notification. We log in to the FortiConverter Service Portal, open the ticket, and from there we can download the converted configuration file and the summary report. There is also information that a certain temporary password has been set for the admin account to access the device. This is also visible in the configuration file.

Editing the Configuration File

We can review the converted configuration file, compare it with the original, or otherwise verify it. We should definitely go through the migration report, which lists any issues and warnings. The new FortiGate is currently connected only to the management network. It is important to check the MGMT interface settings to avoid address conflicts.

In my case of a cluster with In-band management, the original management-ip remained configured, so it needs to be changed. We locate the relevant section in the configuration file and change the address.

config system interface
    edit "mgmt"
        set management-ip 192.168.100.223 255.255.255.0
        set ip 192.168.100.219 255.255.255.0

If desired, we can change the hostname.

config system global
    set hostname "FW1n"

Cluster Group ID - Virtual MAC Address

There is one more important setting related to the HA cluster. The MGMT port is a cluster member and uses a virtual IP address as well as a virtual MAC address, which is active on the primary device (Master). The MAC address is generated in the manner described in Technical Tip: HA Cluster virtual MAC addresses. Therefore, when we restore the configuration to the new FortiGate, the same virtual MAC address will be used and a conflict will occur (MAC is flapping between port).

This can be resolved simply by setting a different Group ID than the current cluster uses. The default value is 0, so we can use for example 1.

config system ha
    set group-id 1

We can check the current settings as follows.

FW1 (global) # get system ha
group-id            : 0

FW1 (global) # get hardware nic mgmt | grep HWaddr
Current_HWaddr      00:09:0f:09:00:01                               
Permanent_HWaddr    04:d5:90:53:61:16
HW_Permanent_HWaddr 04:d5:90:53:61:16

FW1 (global) # get system ha status | grep "HA oper"
Primary: FG3H0xxxxxxxxxxx, HA operating index = 0
Secondary: FG3H0xxxxxxxxxxx, HA operating index = 1

Restoring the Configuration to the New Device

We log in to the new FortiGate and complete the Setup. We skip the migration, optionally disable automatic upgrades, and configure the Dashboard (Optimal).

Then we perform the configuration restore:

  • in the top right corner, click on the logged-in user (Admin)
  • Configuration - Restore
  • upload the configuration file
  • click OK
  • confirm that the global configuration will be restored and the device will restart, using OK
  • after restart, log in with the temporary password and set a new password
FortiGate 7.4 - Configuration - Restore

Adding the Second Device to the Cluster

  • (Global) - System - HA

Note: This topic was described in detail in an older article FortiGate High Availability cluster and Virtual Domains (VDOM). The information is still valid.

The cluster configuration was transferred to the new FortiGate where we restored the configuration. We verify that everything is in order and may adjust priorities.

We log in to the second new FortiGate. It is currently in Standalone mode, which we will change according to our requirements to Active-Passive. We set the same values for Group ID, Group name, Password, and Heartbeat interfaces as on the first device. We confirm with OK and the cluster begins to form (the new node starts joining).

FortiGate 7.4 - System - HA - add to cluster

On the first FortiGate (Primary), the new device will appear as Not Synchronized and synchronization will run for some time.

FortiGate 7.4 - System - HA - Status

In-band Management

At the same time, we will lose direct administrative access to the second box, because the MGMT interface configuration will be overwritten. We can configure In-band management via CLI. We log in to the first FortiGate and connect through it to the second one, where we set the management-ip.

FW1n (global) # execute ha manage ?
<id>    please input peer box index.
<1>     Subsidiary unit FG2H0xxxxxxxxxxx

FW1n (global) # execute ha manage 1 admin
Warning: Permanently added '169.254.0.2' (ECDSA) to the list of known hosts.
admin@169.254.0.2's password: 

FW2n # config global
FW2n (global) # config system interface
FW2n (interface) # edit mgmt 
FW2n (mgmt) # set management-ip 192.168.100.224/24
FW2n (mgmt) # end

Completing the Transition to the New FortiGate

Everything should now be ready for the final switchover. We verify the cluster functionality and review the settings.

Connecting to FortiAnalyzer

If we use FortiAnalyzer, we need to connect/authorize the new devices. This can be done after the final switchover.

Dashboard Configuration

There is one thing that does not get transferred during migration. I think this is an area Fortinet could improve. It concerns Dashboards.

The configuration is saved in the backup, but it can only be accessed in the configuration backup file. It is not displayed via show commands. The configuration is also not synchronized within the cluster. It is separate for each user (a way to copy one user's settings to others would be useful).

We can copy it from the backup and apply it on the new FortiGate for a specific user.

config system admin
    edit "admin"
        config gui-dashboard
            edit 1
        next
        end
        set gui-default-dashboard-template "minimal"
    next

Device Replacement - Firewall Switchover

The final step is to move traffic to the new FortiGate cluster. We plan a maintenance window during which we perform the switchover.

We have a functioning original cluster (FortiGate FW1, FW2) and a new HA cluster (FortiGate FW1n, FW2n). Each consists of a primary unit that processes traffic, and a secondary unit that simply waits for a failover. The secondary unit can be powered off without affecting traffic. Roles change based on device availability, so hopefully the description below is not too confusing.

The procedure that seems most effective to me for minimizing downtime. It may not be necessary to power off the new FortiGate boxes, which could result in an even shorter outage. However, a clean start seems safer to me.

  • power off both new units (FW1n, FW2n)
  • power off the secondary unit of the original cluster (FW2)
  • reconnect the network cables between the secondary units (FW2 > FW2n)
  • power off the primary unit of the original cluster (FW1)
  • outage begins
  • power on the secondary unit of the new cluster (FW2n), it will take a few minutes to boot and will become the primary
  • reconnect the network cables between the primary units (FW1 > FW1n)
  • power on the primary unit of the new cluster (FW1n), it will become the secondary
  • outage ends when the first new unit finishes booting (in my case it took just under 5 minutes, which is approximately the boot time of a FortiGate device)

Shutting Down FortiGate

Via GUI

  • click on the logged-in user in the top right corner
  • System - Shutdown

Via CLI

FW1 # execute shutdown 

This operation will shutdown the system !
Do you want to continue? (y/n)y
System is shutting down...

The system is going down NOW !!

The system is halted.

Powering On FortiGate

To power on a physical FortiGate, the power supply must be restored. Typically, we disconnect and reconnect the power cables.

Author:

Related articles:

Fortinet FortiGate and more

Fortinet security solutions. Mostly focused on the Next Generation Firewall (NGFW) FortiGate. Configuration of FW, policies, NAT, but also VPN and authentication options. Marginally working with logs using FortiAnalyzer and with clients using FortiClient EMS.

Security

Security tools. Primarily Firewall and the like.

If you want write something about this article use comments.

Comments
  1. [1] Bman

    Díky za pěkné shrnutí, ostatně jako vždy :-). Aktuálně jsem dvakrát migroval 40F do novějšího boxu z řady G a FortiConverto se sice nabízel, ale zhodnotil jsem, že rychlejší bude to udělat přes ruční úpravu zálohy konfiguráku z původního boxu. Co se týká FortiOS, obojí na 7.2.13. Bylo potřeba:

    1. přepsat hlavičku v prvním řádku na model nového boxu

    2. v původní záloze upravit část interfaců (s opravou SNMP indexu)

    3. ve zbytku konfiguráku si pohlídat, že tam jsou správně nahrazené jména ifaců

    Ve výsledku to nebyla zase tak velká "drbačka", ale až budu migrovat něco většího.

    Thursday, 26.03.2026 08:48 | answer
Add comment

Insert tag: strong em link

Help:
  • maximum length of comment is 2000 characters
  • HTML tags are not allowed (they will be removed), you can use only the special tags listed above the input field
  • new line (ENTER) ends paragraph and start new one
  • when you respond to a comment, put the original comment number in squar brackets at the beginning of the paragraph (line)