Fortinet Security Fabric Field Cutover Runbook
A Fortinet site cutover affects security policy, routing, switching, wireless and remote management at the same time. TechRunz uses a coordinated runbook that preserves the previous state, confirms supported firmware and topology, validates Security Fabric relationships and proves critical business traffic before closeout.
Make each dispatch repeatable and recoverable
Define prerequisites, remote ownership, method of procedure, acceptance evidence and rollback before technicians arrive onsite.
Firmware, licensing and configuration readiness
Confirm the exact FortiGate, FortiSwitch and FortiAP models, support entitlements, subscriptions and approved firmware combination using current Fortinet documentation. Review release notes and the supported upgrade path rather than assuming the newest release is appropriate for every component.
Stage interfaces, zones, VLANs, routing, SD-WAN, NAT, DHCP, DNS, VPN, identities, policies and logging through client change control. Identify public-address dependencies, partner tunnels, certificates and services that could fail even when general internet access works.
Confirm the FortiGate is running the firmware the staged configuration was built against, since a version gap can change how policies and SD-WAN rules load. Check that FortiCare registration and the FortiGuard subscriptions the design relies on are active, and that a restorable configuration backup exists and has actually been opened by someone.
- Supported firmware combination
- Entitlements and subscriptions
- Policy and dependency review
- Console and rollback readiness
FortiGate, FortiSwitch and FortiAP cutover
Record and label the old appliance ports and provider handoffs before moving cables. Install the FortiGate with local console access available and validate management before transferring production paths. Authorize FortiSwitch and FortiAP devices only after their serials and intended sites are confirmed.
Verify FortiLink physical and logical topology, switch ports, trunks, native VLANs, PoE and managed-device state. For high availability, follow the approved member, heartbeat and synchronization sequence and do not remove the old platform until the new cluster state and rollback decision are clear.
Photograph each port on the outgoing firewall with its label and cable still seated, then keep that unit powered and staged rather than boxed. A hold point before the provider handoff moves and another before the old cluster is disconnected gives the change owner two clean places to say stop.
- Provider and port cable map
- FortiLink and authorization state
- HA sequence and synchronization
- Switch, AP and PoE verification
| Domain | Required proof | Evidence |
|---|---|---|
| FortiGate edge | WAN, route, policy, NAT and VPN | Tests and event logs |
| FortiSwitch | FortiLink, ports, VLANs and PoE | Managed-device and port state |
| FortiAP | Authorization, SSID, identity and client service | Wireless tests |
| Resilience | HA or SD-WAN failure and recovery | Timeline and status record |
Security, connectivity and failure testing
Test each WAN, route, DNS, NAT, published service, site-to-site and remote-access VPN, logging destination and critical application. Verify that traffic is inspected by the intended policy and profile; successful reachability through an unintended rule is not acceptance.
Validate FortiSwitch client ports, voice or device VLANs, FortiAP SSIDs, authentication and representative users. Exercise approved SD-WAN, HA, uplink or power recovery scenarios, observing event logs and session impact. Escalate with timestamps, policy IDs and diagnostic evidence.
Test published services from outside the network as a user would reach them, not only from a workstation behind the firewall. Save the log excerpt showing which policy matched each test, because a session that worked during the visit and fails a week later is argued from records, not memory.
- WAN, NAT, VPN and DNS
- Intended security-policy match
- Client and SSID workflows
- HA and SD-WAN recovery
Secure closeout and support ownership
Capture installed serials, port and VLAN mapping, managed-device authorization, HA state, firmware, licensing, VPN status and acceptance results. Record temporary policies, disabled profiles, unresolved warnings and the owner and deadline for each exception.
Place encrypted backups, certificates, private keys and administrator information in the client-controlled repository. Operations should own FortiCare and FortiGuard accounts, firmware policy, configuration backup, alerting and change approval. Public closeout material should link to official support rather than expose protected files.
Give each temporary rule an owner and a removal date in writing, and flag the broadest one first, since a permissive policy written to finish a cutover tends to outlive the reason for it. Hand operations a short list of what to check on the first business morning after the window.
- Serial, port and firmware record
- Temporary settings and exceptions
- Protected backup and certificates
- Support and change ownership
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Capture state
Export the running configuration, note firmware versions and record the topology the site depends on today.
Align firmware
Match FortiGate, FortiSwitch and FortiAP versions to a supported combination and confirm licensing before the window opens.
Cut with console
Keep console access on the firewall while policy, routing and switching move, so a rollback stays available.
Test business traffic
Test the applications, tunnels and wireless the site actually uses, then fail components deliberately to see what breaks.
Information to gather before design
Fortinet cutovers touch policy, routing, switching and wireless at once, so the change is only as safe as what is known beforehand.
- Current firmware versions on each device
- Support contracts and license entitlements
- Existing policy and routing exports
- Out-of-band console access arrangements
- Applications and tunnels that must stay up
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Should every Fortinet component run the newest firmware?
Not automatically. Use the approved, supported combination and review release notes and upgrade paths for the exact models.
Is internet access enough to approve the firewall cutover?
No. Validate intended policy, VPNs, published services, logging, identity and critical business applications.
Why keep console access during the change?
Management or routing mistakes can remove remote access; a tested local recovery path makes the cutover recoverable.
Where should FortiGate backups and certificates be stored?
In a protected, client-controlled repository with restricted access—not on a public website or general field report.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Schedule a Fortinet Security Fabric cutover
Whether the site can tolerate a policy change and a switch stack change on the same night is the first thing to settle. Send the device inventory, firmware levels, current configuration owner and the window you have.