Kernaali ToolsA configuration file that imports without an obvious error is not proof that a replacement FortiGate preserves the original policy. Map the hardware and dependencies, review import errors, and verify applications and denied access before the cable cutover.
Applies to: FortiGate replacement planning using the FortiOS 7.6.0 best-practices migration procedure and the current Fortinet conversion KB. Both source and target must support the selected firmware path. This is a manual-review checklist, not a universal model converter, an HA migration or a claim that an arbitrary backup can be restored across models.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Choose a supported migration path first
Fortinet’s conversion KB distinguishes same-model/same-firmware restore from cross-model configuration conversion and recommends FortiConverter for automated migration. Its 7.6.0 manual procedure describes an error-prone alternative with matching firmware, backups and interface review. Check the target’s supported firmware before assuming the old build can run there.
Keep protected backups of the old unit and the target’s own configuration, including a tested local management method. Configuration files contain secrets, certificates and identifiers. Work on private copies in a plain-text editor, never a public paste service. Merely changing the model header can make a file acceptable to an importer without making its contents correct.
Map references before importing
| Inventory | Review against the target |
|---|---|
| Physical ports, switches, aggregates and VLAN parents | Actual target interface names and capabilities; preserve each logical role |
| Routes, policy routes, SD-WAN and VPN bindings | Every referenced interface and next hop, including the management path |
| Address/service objects and security policies | Object dependencies, rule order, NAT and policy scope |
| VDOM mode, storage and model-dependent features | Whether the target supports the same layout and feature |
| Certificates, authentication and administration | Required private material, accounts and trust relationships |
Create a role-to-port map such as “inside trunk → target port3” independently of port numbering. Search the private candidate for every old interface reference; changing only the interface definition leaves policies, routes and VPNs pointing at the wrong object.
Read import errors on the isolated target
diagnose debug config-error-log readThe documented command reads configuration import errors; it does not start an IKE or packet debug. Keep the output private. Identify the first rejected section, command or value and compare it with the target’s actual CLI reference. Later errors may be consequences of an earlier missing interface or object.
Correct a reviewed candidate copy and re-apply through the documented target restore process only in the maintenance/staging context. Restoring a complete configuration and rebooting interrupts management and forwarding. Do not test an uncertain import over the target’s only remote connection or on the still-active old gateway.
Validate behavior before cutover
An empty config-error-log is a parsing check, not policy equivalence. Review the target’s resulting configuration against the intended role map. Test management, DHCP/DNS, each important routed path, NAT publication, VPN authentication and the application flows that matter. Include deliberately denied new connections; a broadly permissive imported policy can make positive tests look successful.
The old and new units must not advertise the same production addresses simultaneously on the same live segments. Keep the old unit and cabling plan available for a coordinated replacement window. Record the observed tests and their exact firmware, without assuming this documentation review is a device test.
Rollback to a known working unit or target backup
If acceptance fails, restore the target’s own saved configuration while isolated, or return production cabling to the intact old unit under the planned cutover procedure. Do not reconnect two gateways with conflicting addresses. Retain the failed candidate and a concise private error summary for correction; do not erase useful import evidence before reviewing it.
Separate an IKE migration from a hardware replacement · Prepare new synthetic address-object snippets · Compare prefix coverage, not complete policy equivalence
Technical references
Found an issue? Send a correction with a reproducible example.