The replacement needs a way to receive its configuration
Cloud management creates an apparent circularity: the new appliance needs connectivity to receive the settings that help it provide connectivity. That is manageable, but the bootstrap path must exist independently of the assumption that dashboard configuration will arrive automatically.
Meraki's cold-swap guidance identifies local settings, including static WAN addressing, that need manual configuration before the replacement can connect to Dashboard. It also describes differences between retaining the existing dashboard network and staging a clone. A clone can change dependencies such as the DDNS hostname even when the intended firewall behavior is similar.
The practical implication is that staging must exercise the path the installation actually needs. Successfully downloading a configuration on an office DHCP connection does not establish that a branch with a static handoff is ready. The staging record should identify which conditions were tested and which remain specific to the destination site.
A configuration file carries assumptions about its hardware
Interfaces, storage options and firmware syntax can differ between generations. A rule that references a familiar port name may no longer describe the same physical connection. A file that imports without a prominent error can therefore still require careful functional verification.
Fortinet's conversion guidance limits officially supported direct configuration imports to matching hardware models and firmware versions, and recommends FortiConverter for migration between different targets. That distinction is more useful than an anecdote that editing a backup header worked on another pair of appliances.
For the branch team, the important artifact is the intended relationship between service and interface. WAN transport, trusted network, guest network and any dedicated segment need a verified destination on the new hardware. Copying names is only useful when those names still represent the intended function.
Some dependencies live outside the rule table
Certificates, upstream allowlists, VPN peers and monitoring systems can depend on an identity that changes with the appliance or management network. Meraki's replacement documentation specifically calls for re-adding a custom AnyConnect server certificate when one was used. A successful outbound browsing test would not establish that this remote-access dependency survived.
This explains why a cutover can appear successful to the installer and fail for a different user later. The tested transaction used one service path; the affected user depended on another. A complete migration model needs to connect the appliance to the business functions that rely on it.
The most useful acceptance work follows those functions through the relevant direction of traffic. An outbound cloud application, an inbound service and a site-to-site connection are different dependencies. Passing one should not silently close the others.
Rollback depends on what the cutover changed
Keeping the old firewall nearby does not by itself preserve a working return path. The migration may alter dashboard membership, upstream settings, cabling or credentials. If those changes are not reversible within the remaining window, the physical presence of the old box provides less protection than expected.
A meaningful rollback decision considers the complete earlier state and the time needed to restore it. The deadline belongs before the point where the business can no longer reopen on schedule. Waiting until every troubleshooting idea has been exhausted converts a planned fallback into another emergency change.
This does not require abandoning a migration at the first unexpected result. It requires distinguishing a bounded correction from an open-ended investigation. The team needs enough evidence to know which kind of problem it is facing while a usable return path still exists.
Readiness should reduce work inside the outage window
The highest-value preparation resolves questions that do not require the live branch to be offline: compatible firmware, interface mapping, management access and the expected service paths. The maintenance window can then focus on the physical change and the remaining site-specific verification.
Cartennas's conclusion is that a firewall replacement is ready when its dependencies and recovery path are understood, not merely when a configuration file is available. That standard makes the cutover easier to coordinate and gives the business a clearer account of what a successful installation must restore.