Follow the supported Fortinet sequence rather than skipping required intermediate builds.
Backups, local certificate considerations and recovery access should be planned before firmware work.
Check FortiManager, FortiAnalyzer, Security Fabric and other dependencies against the target release.
Traffic, VPN, authentication, inspection and integrations need functional checks after reboot.
Direct answer: what a Fortinet firewall upgrade involves
A Fortinet firewall upgrade is the planned movement of a FortiGate appliance or cluster from its present FortiOS firmware to another supported release. The work usually includes checking the device model and entitlement, selecting an appropriate target release, reviewing the supported upgrade path, reading release notes, backing up the configuration, confirming recovery access, scheduling a maintenance period and validating business services afterward. Organisations should consider an upgrade when the current build is outdated, a supported release is required for security or compatibility, a feature dependency exists, or lifecycle planning calls for a newer FortiOS train. Before proceeding, confirm the exact model, current build, integrations, HA arrangement, critical VPNs, change window and rollback approach.
What the upgrade service is designed to do
The purpose is to move the firewall to a suitable firmware state without treating the production network as a test environment. That means understanding what the firewall currently does, what the target release changes, and what must remain available when the unit restarts. A firewall may be handling routing, NAT, security profiles, site-to-site IPsec tunnels, remote access, SD-WAN, VLAN segmentation, authentication, DNS services, DHCP, published servers or Security Fabric relationships. The upgrade plan should preserve these functions and establish a method for proving that they still work after the change.
The work can range from a single small FortiGate at an office edge to an HA cluster, multi-branch estate or centrally managed deployment. Scope therefore depends on the number of appliances, current versions, distance between source and target releases, network complexity, access method, support entitlement and the amount of testing required.
Who should consider planned FortiGate firmware work
A structured upgrade is relevant to businesses that rely on the firewall for continuous connectivity and cannot accept an unplanned change. This includes companies with branch VPNs, cloud-hosted applications, internet-facing services, remote users, dual-WAN routing, security inspection, high availability or integrated Fortinet management. It is also useful when an internal IT team wants a second review of the upgrade path and release notes before performing the change.
An upgrade may not be the correct answer when the appliance itself no longer supports the desired FortiOS release, the hardware is near the end of its useful lifecycle, the configuration requires major redesign, or the support contract does not permit the required firmware access. In those cases, a hardware refresh, license renewal, migration project or configuration remediation may need to be planned first.
Business problems an upgrade plan helps address
Unsupported or ageing firmware
Older software may no longer align with current support expectations, security recommendations or integration requirements. The correct response is to identify a supported destination and follow the vendor-defined path rather than jumping blindly to the newest number.
Compatibility drift
FortiGate does not operate in isolation. FortiManager, FortiAnalyzer, FortiSwitch, FortiAP, authentication systems and third-party services can create version dependencies that must be reviewed before the firewall is changed.
Configuration risk
Feature behaviour, CLI syntax and defaults can change between releases. Review of release notes, pre-upgrade configuration, error logs and post-change behaviour reduces the chance of discovering a meaningful difference only after users are affected.
Unclear rollback readiness
A change window is safer when the team knows how it would regain console access, use the previous firmware image, restore configuration, switch partitions where applicable or escalate to vendor support if the expected boot sequence does not complete.
Buyer information for a Fortinet firewall upgrade project
| Topic | Fortinet FortiGate firmware upgrade planning and implementation support |
| Main purpose | Move a supported FortiGate environment to a suitable FortiOS release using an approved upgrade path and controlled change process. |
| Suitable for | Standalone appliances, HA clusters, branch firewalls, Security Fabric environments and centrally managed deployments, subject to scope review. |
| Assessment support | Current version, model support, release maturity, upgrade path, known changes, support entitlement and dependencies. |
| Configuration support | Backup planning, configuration review, recovery preparation and post-upgrade checks; exact activities depend on environment. |
| Integration review | FortiManager, FortiAnalyzer, FortiSwitch, FortiAP and other systems should be checked for target-version compatibility where present. |
| License guidance | Firmware access can depend on FortiCare or Firmware & General Updates entitlement and current vendor policy. |
| Remote or on-site coordination | Depends on console availability, site risk, device accessibility and the agreed rollback plan. |
| Availability guidance | Contact FourTeck to confirm UAE service scheduling, project scope and access requirements. |
| Important note | No target version should be assumed suitable until the exact FortiGate model, current build and dependencies are checked. |
Configuration, licensing and compatibility dependencies
Fortinet documents several checks that should happen before firmware installation: understand the maturity level of the target release, review release notes, confirm the supported upgrade path, retain the currently installed firmware, keep a recovery plan and back up the configuration. These steps matter because firmware can introduce behaviour changes and because skipping required intermediate releases can create configuration problems. The current FortiOS documentation also advises confirming integration compatibility before the change.
Firmware entitlement deserves separate attention. Depending on the FortiOS train and current Fortinet policy, moving between major or minor releases can require a valid Firmware & General Updates entitlement. A project should therefore confirm the FortiGate registration and contract state before the maintenance window rather than discovering an entitlement block during the change. If FortiManager, FortiAnalyzer or Security Fabric components are involved, their supported combinations should be checked as part of planning.
Backups should be treated as recovery assets, not as a formality. A full configuration copy should be stored off the device. Local certificates may require separate handling because some FortiGate-generated certificates are not included in a normal configuration backup. Where the upgrade is remote, console or physical recovery access should be practical enough to support a failed boot or connectivity issue.
A practical FortiGate upgrade journey
Discovery
Record model, serial context where appropriate, current FortiOS, topology, HA state, WAN links, VPNs, security services, management platforms and business-critical traffic.
Target selection
Choose a suitable supported release based on model support, maturity, lifecycle, known issues, feature needs and integration compatibility rather than choosing the numerically newest build by default.
Change preparation
Follow the supported upgrade path, back up configuration, retain current firmware, prepare console recovery, confirm stakeholder approval and define pass/fail checks.
Upgrade and validation
Complete each required step, allow reboots, check configuration status, verify traffic and integrations, document the result and only then close the maintenance task.
Choosing the target FortiOS release with operational context
A version number alone does not tell an IT team whether an upgrade is appropriate. Fortinet distinguishes firmware maturity and provides release-specific information, supported model lists, known issues and upgrade guidance. The target should be evaluated against the reason for the change. A business seeking long-term stability may place different weight on mature releases than a lab that needs a newly introduced feature. A firewall moving from an end-of-support train may have several viable destination trains, each with different path complexity and support timelines.
The path itself can contain multiple intermediate builds because configuration structures can change between releases. Treating those steps as optional can defeat the purpose of the vendor’s upgrade design. Where several steps are required, the maintenance plan should include enough time for each reboot, synchronization and validation activity. The objective is not to rush to the target build; it is to arrive there with a usable configuration and predictable network behaviour.
Known issues also deserve active review. A new release may resolve an existing problem while introducing a change that affects SSL inspection, routing, VPN, authentication, HA or another feature used by the organisation. Release notes should therefore be compared with the actual configuration. FourTeck can help translate the release information into environment-specific questions so the decision is based on the services the firewall really provides.
Backup and rollback planning before firmware installation
A backup is useful only when the team knows where it is stored, which firmware it belongs to and how it would be restored. Before a FortiGate upgrade, the current configuration should be saved away from the appliance and labelled with the device, date and source firmware. If local certificates are important to SSL inspection or published services, verify whether they require a separate export. The currently installed firmware should also be available when practical so a recovery workflow does not depend on finding an old image during an outage.
Rollback means more than having a file. The team should know what conditions trigger rollback, who makes that decision, how management access will be regained, and how long validation will be allowed before returning to the previous state. Console access is particularly important for remotely located units because an IP-addressing, boot or configuration issue can remove the very path being used to administer the firewall.
Downgrading can have configuration consequences, especially across major releases. A pre-change backup from the original firmware provides a known reference point. For HA deployments, rollback planning should also consider the cluster state and how both members will be kept at compatible firmware. FourTeck can include backup verification and rollback documentation in the agreed service scope where required.
High availability, FortiManager and Security Fabric upgrades
A FortiGate HA cluster is not simply two independent devices with the same configuration. The members have synchronization, failover and session-handling behaviour that must be considered before a firmware change. Fortinet’s current guidance describes a staged, failover-aware upgrade process for FGCP clusters and recommends verifying that the cluster is synchronized before proceeding. Session pickup settings can affect continuity for existing traffic, so the design should be reviewed rather than assumed.
FortiManager-managed estates add another layer. The FortiManager version, ADOM support, policy package status and chosen FortiGate target release must be compatible. In a larger branch environment, centralized firmware scheduling can improve consistency, but a single plan may still need different windows for locations with different business hours or connectivity. Administrators should avoid turning central management into centralised risk by pushing an unreviewed release to all sites at once.
Security Fabric deployments may involve FortiSwitch, FortiAP and other components whose firmware relationships matter. Fabric Upgrade features can coordinate supported devices, but the root FortiGate target and component compatibility should be checked first. FourTeck can help map the dependency chain, define an upgrade sequence and separate what can be automated from what still requires manual validation.
Where planned upgrades are especially important
Multi-branch companies
Branch firewalls often terminate VPNs and provide local internet breakout. A failed upgrade can isolate an entire site from cloud applications, voice systems or head-office resources. Staging and branch-by-branch validation can reduce operational impact.
Hotels, retail and customer-facing sites
Guest connectivity, point-of-sale traffic, reservations, payment gateways and cloud applications can make the firewall change window commercially sensitive. Critical flows should be explicitly documented and tested after the reboot.
Offices with remote access
VPN behaviour, authentication and endpoint compatibility may affect remote staff. The test plan should include both internal internet access and representative remote connections rather than relying only on the firewall dashboard.
Data centre and server-edge environments
Public services, internal segmentation, dynamic routing and high session volumes can make validation more complex. These environments generally need a defined rollback threshold and application-owner participation.
FortiManager-managed estates
Centralized management makes scale possible but requires compatibility discipline. Pilot sites, grouped windows and device-health checks can help a large rollout proceed without assuming every site is identical.
Security Fabric deployments
The firewall may coordinate switches, access points and other fabric components. Version relationships and fabric-health checks are part of the upgrade decision, not optional housekeeping after the event.
Integration and operational checks after the reboot
A successful login after a firmware upgrade is not proof that the network change succeeded. Validation should reflect the services users and applications depend on. Start with system health, interface status, routing, DNS reachability and policy counters. Then test representative internet access, site-to-site VPNs, remote access where applicable, published services, application authentication, SD-WAN path selection and any dynamic routing adjacencies. If the firewall forwards voice, CCTV, payment or other specialised traffic, test those paths as well.
Security functions should also be observed. Confirm that security profiles load, logging reaches the expected destination, FortiGuard updates are healthy and integrations reconnect. If FortiAnalyzer is used, confirm log ingestion; if FortiManager is used, check management status and configuration synchronization. In HA, verify both members are healthy, synchronized and running the intended firmware before declaring the change complete.
Configuration comparison can help identify unexpected changes. Fortinet’s guidance recommends validating configuration integrity and checking important services after the upgrade. The point is not to compare thousands of lines manually without context; it is to investigate relevant changes and any errors surfaced during the upgrade. FourTeck can define a post-change checklist based on the actual topology so the team knows what “working” means before the maintenance window starts.
Questions to resolve before ordering upgrade support
What exact FortiGate model and FortiOS build are running?
The model determines which FortiOS releases are supported. The current build determines the correct upgrade path and how many intermediate steps may be required.
Is the appliance standalone, HA or centrally managed?
Cluster upgrades and FortiManager-managed upgrades have different planning considerations. The topology also affects rollback and validation.
Which business services depend on the firewall?
List VPNs, cloud applications, public servers, branch routes, internet access, authentication, VoIP, payment systems and other critical traffic so validation can be meaningful.
Is valid firmware entitlement available?
Support status can affect access to major or minor firmware upgrades. Contract state should be confirmed before scheduling the change.
Can someone reach the console if remote access fails?
For high-risk remote upgrades, local recovery capability can be the difference between a short interruption and an extended outage.
What is the acceptable maintenance window?
The number of required upgrade steps, cluster synchronization and testing time should fit inside a business-approved window with room for rollback.
FortiGate upgrade procurement checklist
Providing these details before a quotation helps separate a simple firmware task from a broader change project. A single office firewall may need only a short assessment and controlled update, while a multi-site estate with HA, FortiManager, FortiAnalyzer and many VPN dependencies can require staged planning and several maintenance periods.
How FourTeck can assist with planning and execution
FourTeck’s role can begin before the change window. The team can review the existing FortiGate model and firmware, identify the supported vendor path, compare the target release with the business requirement, check known release considerations and build a change plan that includes backup and recovery tasks. If the environment includes FortiManager, FortiAnalyzer, HA or Security Fabric components, those dependencies can be included in the review rather than treated as separate surprises.
During implementation, scope can include configuration backup coordination, firmware staging, execution of the approved upgrade steps, cluster-status monitoring, device-health checks and post-upgrade testing. The exact service can be remote or coordinated on site depending on risk, access and location. A remote change should not be assumed appropriate when console recovery is unavailable or the device is too critical to operate without local support.
After the upgrade, FourTeck can help review connectivity, VPNs, security services, routing, logging and management integrations. If errors or unexpected behaviour appear, the next action may be configuration remediation, vendor escalation, rollback or a follow-up maintenance window. Service scope should be agreed before work starts so the buyer knows whether the quotation covers assessment only, upgrade execution, extended testing, on-site attendance, documentation or ongoing support. Explore broader firewall services or Fortinet firewall guidance when the requirement also includes hardware, licensing or migration.
UAE availability and support guidance
Businesses can contact FourTeck to confirm current UAE availability for Fortinet firewall upgrade assessment, planning and implementation support. Scheduling depends on the FortiGate model, number of devices, existing firmware, support entitlement, whether access is remote or on site, the required change window and the depth of post-upgrade testing. A quote should identify whether the work covers only firmware installation or also configuration review, FortiManager or FortiAnalyzer compatibility checks, HA validation, backup verification, rollback planning and documentation.
Delivery and project coordination can be discussed after the exact requirement is confirmed. If a license renewal, hardware replacement or new appliance is required, that commercial scope should be separated clearly from the engineering effort. Installation and configuration tasks that fall outside the firmware upgrade should also be included in the quotation when required. Use the FourTeck contact page to share the current model, firmware build, site location, preferred window and business-critical services.
Dubai, Abu Dhabi, Sharjah and Ajman coverage
Organisations in Dubai, Abu Dhabi, Sharjah and Ajman can request FortiGate upgrade planning, quotation assistance and service coordination from FourTeck. The practical delivery method depends on the device and risk profile. Some upgrades may be suitable for controlled remote execution when management and console recovery are available, while others may justify on-site attendance because the firewall is a critical gateway, sits in an HA pair, supports complex VPNs or lacks dependable out-of-band access. Buyers should share the site, maintenance-window preference, number of appliances, existing versions and whether local IT staff are available during the change. FourTeck can then help define a scope that matches the environment instead of assuming that every upgrade is the same.
GCC Availability
FourTeck can assist organisations planning Fortinet firewall upgrades across GCC environments, including projects where the central IT team is in the United Arab Emirates but FortiGate appliances are deployed in Saudi Arabia, Kuwait, Qatar, Bahrain or Oman. Regional work begins with the same technical facts: exact model, current FortiOS, desired target, support entitlement, management platform, HA status and business-critical connectivity. From there, FourTeck can help with requirement review, release and path assessment, quotation coordination, configuration scope, remote-change planning, installation considerations and renewal guidance where licensing affects firmware access. Availability, service visits, delivery of any replacement hardware, license processing, project timing and vendor lead time can vary by country, model, quantity and scope. Buyers should confirm the destination country, firewall count, license state, access method and preferred maintenance schedule before a regional plan is prepared. For Kuwait-related business technology requirements, buyers may also review FourTeck Kuwait information.
Africa Availability
Fortinet firewall upgrade projects in Africa may involve headquarters, branch offices, data centres, retail locations or distributed sites managed from another region. FourTeck can help organisations review firmware versions, model support, license status, VPN dependencies, backup readiness, configuration scope and the practical method for executing the change. The project may also include replacement planning when older hardware cannot run the intended FortiOS release. Availability and fulfilment depend on the destination, product model, number of devices, license region, power and site requirements, shipping arrangements for any hardware, vendor lead time, maintenance-window constraints and local support conditions. Buyers should share the destination country, exact firewall requirement, quantity, preferred deployment schedule and on-site support expectation so the correct scope can be discussed. For regional enquiries, explore FourTeck Africa, FourTeck Kenya or FourTeck Uganda. No local inventory, customs outcome, visit schedule or delivery timing should be assumed until confirmed for the specific project.
Related FourTeck options to consider
Fortinet firewall sizing
Useful when the current appliance cannot support the intended release, bandwidth, inspection load or future growth.
Firewall migration
Consider a structured migration when firmware alone cannot resolve lifecycle, performance or architecture constraints.
License and renewal guidance
Firmware entitlement and security-service subscriptions should be checked before a major or minor upgrade is scheduled.
Firewall configuration review
An upgrade can be a good time to identify old rules, unclear objects or operational issues that deserve a separate remediation plan.
Why businesses contact FourTeck for FortiGate upgrade work
The value of outside assistance is not the firmware upload itself. It is the structured review around the change. Businesses contact FourTeck when they want help clarifying the current state, identifying a supported upgrade path, checking whether licensing or hardware creates a blocker, mapping business services to validation steps and preparing a rollback plan that can actually be executed.
FourTeck can also help procurement and technical teams communicate using the same scope. A quotation can distinguish assessment, change execution, on-site attendance, after-hours scheduling, HA or FortiManager work, testing, documentation and follow-up support. This matters because a low-complexity office firewall and a multi-site managed estate should not be priced or scheduled as if they require identical engineering effort.
The same practical approach applies when the correct recommendation is not an upgrade. If the model cannot run the required FortiOS release, the support contract is expired, the configuration is too risky to change without remediation, or the business needs a broader hardware refresh, FourTeck can help define the next action rather than forcing the original request into an unsuitable scope.
What buyers are trying to understand before a FortiGate upgrade
The most common upgrade question is deceptively simple: “Can I go straight to the latest FortiOS?” For a production FortiGate, the safe answer is to check the supported Upgrade Path Tool for the exact model and starting build. Fortinet’s own guidance warns that intermediate versions can be required, and skipping them may cause configuration problems. The target should also be selected using release maturity, lifecycle, known issues, feature requirements and integrated-product compatibility. A branch office with a stable feature set may have a different best destination than a lab testing newer capabilities.
Buyers also ask whether a firmware change can be done remotely. It often can, but the risk is not defined by distance alone. The important question is whether there is a recovery route if the firewall does not return to normal management access. If console access is available through an out-of-band system or a competent local contact is present, a remote change can be practical. If the site has no alternative path, no local hands and the firewall carries every business service, an on-site or more conservative plan may be preferable.
Another frequent concern is downtime. The reboot itself may take only a short period, but the maintenance window should include much more than reboot time. A supported path may require several sequential upgrades. HA members may need synchronization. VPNs, routing, authentication, internet access, published applications and security integrations must be tested. If something unexpected happens, the team needs enough time to investigate or roll back before normal business use resumes.
Licensing questions are equally important. Current Fortinet documentation explains that major or minor firmware upgrades can depend on an active Firmware & General Updates entitlement. A team should confirm the device registration and contract status before the planned change. This is particularly important when upgrading older firewalls that may have lapsed support. If entitlement is missing, the project may need a renewal or a different lifecycle decision before engineering work begins.
Businesses often ask whether the upgrade will preserve configuration. The supported upgrade process is intended to carry the configuration forward, but release changes can affect syntax, behaviour or feature handling. That is why Fortinet recommends configuration backup, release-note review and post-upgrade validation. The configuration is not only a set of firewall rules: it can include interfaces, static and dynamic routes, SD-WAN, NAT, VPNs, authentication, certificates, security profiles, logging and system settings. A meaningful test plan should be built around those actual functions.
There is also growing interest in FortiManager-driven upgrades for multi-site environments. Centralized firmware management can reduce repetitive work and improve consistency, but it does not eliminate change control. Device groups may have different business hours, WAN resilience or application dependencies. A prudent rollout can start with a representative pilot site, review the result, and then proceed in groups. For HA clusters, the health and synchronization of all members should be checked before the upgrade starts.
Finally, buyers ask what information is needed for an accurate quote. The most useful starting package is the FortiGate model, current FortiOS build, number of devices, HA or standalone status, FortiManager and FortiAnalyzer use, support entitlement, critical VPNs, site location, preferred maintenance window and desired target outcome. If the buyer does not know the target release, that is acceptable; target selection can be part of the assessment. What matters is providing enough environment detail to distinguish a routine patch from a multi-step, high-impact change.
Practical questions buyers ask during upgrade planning
How do we know whether to choose a Mature or Feature release?
Start with the business requirement, not the label alone. Mature builds are positioned around established stability, while Feature builds may introduce newer capabilities. The exact target should also be checked for model support, known issues, lifecycle and integration compatibility. If the firewall is stable and no new feature is required, a conservative target may be sensible. If a required function exists only in a newer train, the decision should include testing and operational impact.
What if our current FortiOS is several releases behind?
Do not assume that a large jump is supported. Use the Fortinet Upgrade Path Tool for the specific model and starting build. The path may include multiple intermediate releases, each of which can apply configuration conversions needed by the next step. The maintenance plan should include time for every required reboot and health check. If the model cannot reach the desired train, hardware lifecycle planning may be necessary.
Should we upgrade FortiManager or FortiGate first?
The answer depends on the exact versions and supported compatibility matrix. Central management and the managed FortiGates must remain within supported combinations. The project should therefore review FortiManager, ADOM and FortiGate target versions together. FourTeck can help sequence the work when multiple platform upgrades are required rather than treating each component as an independent change.
Can we upgrade without a support contract?
Firmware entitlement depends on the FortiOS release and current Fortinet policy. Current documentation states that a valid Firmware & General Updates entitlement is required for moving to another minor or major version. Contract state should be checked on the actual device before scheduling the work. If the required entitlement is not active, renewal guidance should become part of the project.
What should we test after the upgrade?
Test the services that matter to the business: internet access, WAN failover, site-to-site VPN, remote access, application publishing, DNS, authentication, routing, security inspection, logs and management integrations. HA deployments should also verify cluster health and synchronization. A generic “the firewall is online” check is not enough because an appliance can be reachable while an application path is still broken.
When should we replace hardware instead of upgrading?
Consider replacement when the model is not supported by the target FortiOS release, when performance no longer matches inspected traffic, when interface or HA requirements have changed, or when lifecycle and support constraints make continued use impractical. Firmware cannot add physical capacity or extend a platform beyond its supported model matrix. A hardware refresh should be assessed separately with migration and license requirements.
Frequently asked questions
1. What is included in a Fortinet firewall upgrade service?
Scope can include current-state assessment, target-release review, supported upgrade-path validation, configuration backup planning, firmware execution, HA or management checks, rollback preparation and post-upgrade testing. The final quotation should state which of these activities are included.
2. Can a FortiGate jump directly to the newest FortiOS?
Not necessarily. Fortinet provides a supported Upgrade Path Tool because some source and target combinations require intermediate firmware versions. The exact model and current build must be checked before choosing the sequence.
3. Is a configuration backup required before upgrading?
Yes, a current configuration backup is a core precaution. Recovery planning may also include the current firmware image, console access and separate handling of local certificates where relevant.
4. Will a FortiGate firmware upgrade cause downtime?
A standalone FortiGate normally restarts during the upgrade, so traffic interruption should be expected. HA can reduce disruption in supported designs, but continuity depends on cluster health, session handling and topology. The maintenance window should include testing and rollback time.
5. Can FourTeck upgrade an HA FortiGate cluster?
HA upgrade support can be scoped after reviewing the cluster mode, member health, synchronization, current versions, session requirements and management method. Both members should be healthy and synchronized before proceeding.
6. Do FortiManager and FortiAnalyzer versions matter?
Yes. Integrated Fortinet products must be checked against the target FortiOS release. A firewall upgrade can require a coordinated management or logging-platform plan when existing versions are outside supported combinations.
7. Do we need an active FortiCare contract?
Firmware access and the ability to move between certain major or minor FortiOS releases can depend on the current Firmware & General Updates entitlement. Confirm the device contract state before the project is scheduled.
8. Can the upgrade be performed remotely in Dubai or the UAE?
Remote work may be practical when stable management access and a recovery path are available. On-site coordination may be preferable for high-impact gateways, complex environments or sites without dependable console recovery. The access model should be agreed during scoping.
9. What information is needed for a quotation?
Share the FortiGate model, current FortiOS build, device count, HA status, FortiManager or FortiAnalyzer use, support entitlement, important VPNs, site location, desired outcome and preferred maintenance window.
10. What happens if the firewall is too old for the target release?
A hardware refresh or migration may be required. FourTeck can help compare lifecycle, model sizing, licensing and migration needs instead of attempting an unsupported firmware path.
Plan the upgrade around your real FortiGate environment
Send FourTeck the firewall model, current FortiOS build, HA or management details, support status and preferred maintenance window. The team can review the requirement and prepare a suitable upgrade, renewal, migration or replacement scope.
Reviews
There are no reviews yet.