These are some examples of issues, in no particular order, that have been brought to the attention of the Technical Assistance Center or the Documentation Team that could impact the success of a firmware upgrade.
Standalone vs. HA configuration upgrades
In version 5 there is a difference in the steps between the patches depending on whether your FortiGate setup is in a standalone or an HA configuration. If you have a standalone setup, you can upgrade from Patch 3 (5.0.3) directly to Patch 5 (5.0.5). However, if you are using an HA setup, you need to add the intermediate step of going to Patch 4 (5.0.4). Otherwise, only the slave unit in the configuration will be upgraded to Patch 5.
In the table describing the steps in progressing through the upgrades the most cautious path is listed. This minimizes the possibility of confusion for somebody who has an HA cluster but reads the Release Notes, like everybody should, but was unaware of the known issue with the HA clusters.
Max Value issues
There is a range of builds where the maximum number of some of the objects was lowered, but then a few builds later were raised back up. If the configuration on a device was to have a number of these objects in excess of the lower value when doing an upgrade, there could be issues and even data loss. The upgrade paths listed are designed to avoid upgrading into this lower max value range even though the Release Notes state that upgrading to these firmware builds is supported. When the release notes were written the act of increasing the values was not foreseen.
Seemingly unrelated features can sometimes affect Max Value parameters after an upgrade. For instance, a feature introduced in 5.4 affected the max number of application control sensors. The feature added a “sniffer-profile“, which could not be deleted, upon the creation of a VDOM. The normal max number of application sensors could be 32 but if you had 10 VDOMs, that number was effectively usable sensors (32 – 10 = 22).