F5 BIG-IP Upgrade: Important Prerequisites

Most BIG-IP upgrade problems can be prevented with preparation. The installation itself is usually the easy part. Choosing the right target version, confirming prerequisites and having a tested rollback plan is where the real work is.

This article covers the prerequisites to work through before scheduling a maintenance window.

This is general planning guidance, not an upgrade procedure. Always follow F5's official upgrade documentation and release notes for your exact source and target versions.

1. Choose the target version deliberately

• Support lifecycle. Check where both your current version and the candidate target are in F5's support lifecycle. Upgrading to a version that is itself close to end of support creates more work soon after.
• Release notes and known issues. Read them for the target version, especially anything affecting the modules and features you use.
• Platform support. Confirm the target version is supported on your hardware platform or Virtual Edition environment.
• Upgrade path. Some older versions can't be upgraded directly to the newest releases. The release notes describe supported upgrade paths.

2. Check the licence service check date

Each BIG-IP licence has a service check date, and each software version has a licence check date. If the service check date on your licence is earlier than the licence check date of the target version, the configuration may fail to load after the upgrade.

Reactivating the licence before the upgrade updates the service check date. Do this ahead of the maintenance window, not during it.

3. Confirm disk space and software volumes

BIG-IP installs new software into a separate boot location (software volume) and leaves the current one in place. This is what makes rollback practical: if the new version doesn't behave, you can boot back into the previous volume.

Before the window, confirm there's an inactive volume available, or that you can create one, and that there's enough disk space for the installation image.

4. Take backups and store them off the device

• UCS archive. Create a fresh UCS archive of the configuration immediately before the upgrade and copy it off the device.
• Master key. Some configuration attributes are encrypted with the device's master key. Restoring a UCS archive onto a different or replacement device requires that master key, so make sure you know how it's managed and stored securely.
• Supporting files. Certificates and keys, custom monitors, external data group files and any scripts should be accounted for.

5. Review the configuration for compatibility

• Which modules are provisioned, and are they all still required?
• Are there deprecated features or iRule commands that behave differently in the target version?
• Are there integrations, such as remote logging, SNMP, authentication servers or automation tools, that need testing afterwards?

F5's iHealth service can analyse a QKView diagnostic file from your system and highlight known issues and upgrade-related advisories. It's worth running well before the window.

6. Plan the maintenance window

• Change approval and stakeholder communication.
• A step-by-step plan based on F5's documentation for your versions.
• A verification checklist, written in advance: virtual server and pool status, monitor results, log review and real application tests by the application owners.
• A rollback plan with a clear decision point: what would make you roll back, and who decides.

Standalone devices and HA pairs

Everything above applies to every upgrade. Devices in a high-availability group need extra planning on top of it: the order in which devices are upgraded, failover between them, and configuration synchronisation while they run different versions. F5 publishes specific guidance for upgrading HA configurations, and it should be followed closely.

After the upgrade

• Confirm the system booted into the expected version and the configuration loaded without errors.
• Check licence status and module provisioning.
• Compare virtual server and pool member status with your pre-upgrade baseline.
• Review the logs for new errors.
• Have application owners confirm their applications work as expected.
• Keep the previous boot location until you're confident the upgrade is stable.

Preparation won't remove every risk, but it turns an upgrade from a leap of faith into a controlled change with a way back.