FortiGate Config Migration: Interface Mapping and Import Errors

Read the rejected command and its configuration path

diagnose debug config-error-log read

For each rejected line, locate its enclosing config and edit blocks in the candidate file. Compare that block with the target’s resulting configuration. Start with the first rejected interface or object; later errors may be references to that missing definition:

If the import log gives only a generic error, re-enter the rejected statement in its correct config/edit context on the staged target. The interactive CLI can give a more specific reason. This executes the statement if accepted, so it is a target configuration change, not a read-only replay. Fortinet’s import-debugging procedure explains the log fields and this diagnostic method.

Save the failed import log before changing the file so you can compare the next import against it.

Repair a rejected VLAN parent

For example, the candidate creates VLAN users20 on old port port3, but the target mapping uses port5. On the staged target, read:

show system interface port5
show system interface users20

Confirm port5 exists, belongs to the intended VDOM and is available for the planned VLAN parent. In the candidate file, find edit "users20" under config system interface and change its parent from set interface "port3" to set interface "port5". Keep its intended vdom, vlanid and IP/mask. If the whole VLAN was rejected, retain the entire corrected object, before the policies and routes that use it.

Search the candidate for the exact token "port3". Update only references to the role moved to port5, including direct policy/route/VPN bindings; references to "users20" keep that logical name. Do not replace every occurrence blindly: a switch member or another VDOM may need a different mapping. Unsupported physical/switch layouts must be resolved against the target interface inventory before importing.

Map interfaces and their dependencies

Match each logical role to the target hardware: WAN, VLAN trunk, aggregate member, switch member and management. Then update references in VLAN parents, routes, SD-WAN members, VPN bindings, policies and DHCP servers. Replacing a port name only under config system interface leaves these dependencies unresolved.

Fortinet’s manual migration procedure uses matching firmware and a header taken from the target’s own backup. Check support on both models first. The header identifies the target; it does not translate hardware-dependent settings. Fortinet recommends FortiConverter for cross-model conversion.

Diff the loaded result, then re-import

In the target GUI, use the upper-right administrator menu → Configuration → Backup to save the pre-import state privately.

Then choose Configuration → Restore → Upload, select the corrected candidate and restore it. The target reboots and management addressing may change.

After reconnecting, read diagnose debug config-error-log read again and use the same Backup menu to save the loaded result. Compare that file with the candidate in a text diff, starting with each rejected configuration section.

For the VLAN example, read show system interface users20 again and verify interface "port5", VLAN ID, VDOM and address. In the receiving VDOM, use show firewall policy to compare policy order and srcintf/dstintf; use get router info routing-table details <test-destination> to check the installed next hop.

For migrated VPN traffic, follow the selector, policy and route procedure. Compare address-group membership with CIDR list comparison when prefix coverage is the question.

Verify the migrated policies and VPNs

Start a new connection for a required routed service, a published VIP service and each migrated VPN. In Log & Report → Forward Traffic, filter by the test source/destination and open the session details. Compare the policy ID, egress interface and NAT fields with the intended policy. If the policy does not log, use the short flow trace to identify the selected policy and translation.

Also test a flow that must remain denied and an actual login for each migrated user/certificate VPN. Retain the candidate and import errors with the target backup until these checks succeed.