You set one appliance in your cluster to "ForcedOffline" status while it's being upgraded. When done, you perform a network failover and repeat the upgrade on other unit.
Before you upgrade the second unit, you ask application specialists and other stakeholders to verify if services work as intended with new BigIP version active. You also do your own due diligence, i.e. monitoring /var/log/ltm to swiftly spot any errors and address them on the go. In ideal conditions, the impact of a major upgrade is a session disruption during cluster failover (SSL/TLS sessions may break). Depending on applications, this may mean clients have to re-login and that's about it (impact of a few seconds). In a more stressful scenario, some applications may require cold server reboots to restore services. If all is well coordinated, first server should be available within 10-20 minutes.
With that said, major upgrades are major projects. The more modules you have, the more problems you will face. Most problems are configuration load errors that do not cause an impact on production. Worst-case impact includes subtle problems that are not obvious. I.e. silently changed values in vendor default profiles may show first signs of negative impact hours or even days after the upgrade itself is already completed. It takes a seasoned BigIP upgrade expert to pull off a major software upgrade with less than 10 minutes of downtime or notable service degradation.
If it's your first time, and you have at least 2 active BigIP modules or 50 Virtual Servers in LTM-only setup, assume the following. 30 mins full downtime for at least 1 service, 1 hour service degradation for at least 1 service, and 2 days of your own time to troubleshoot configuration load errors.
It would help if you have a place to emulate your upgrade, a BigIP lab
Nimbostratus
