Server Firmware Updates: When to Apply and When to Wait

"Keep firmware up to date" is repeated as though it were unambiguous advice. It is not. Firmware updates fix real problems and cause real ones, and the sensible approach is neither updating everything immediately nor never updating at all.

Why firmware is different from software

Three properties make it a different kind of risk.

Failure can be unrecoverable. An interrupted firmware update can leave a device that will not start and cannot be updated again. Recovery procedures exist on many platforms, and they are considerably more involved than reinstalling an application.

Rollback is frequently unavailable. Many devices will not accept an older firmware version once updated. If the new version causes a problem, going back may not be an option.

It is part of a tested combination. Compatibility lists specify firmware versions alongside hardware and drivers, and the combination is what was validated. Newer is not automatically safer — firmware ahead of what the driver expects is an untested configuration. Our compatibility guide covers this.

That third point is the one that surprises people who apply operating system patching habits to firmware.

When to update

Four situations where the case is clear.

A security vulnerability affects you. Management controllers in particular — they run whenever the server has power, so a vulnerability is reachable even when the server is nominally off. Our management guide covers why a compromised controller is worse than a compromised operating system.

You are experiencing a problem the release notes address. The most defensible reason of all: a specific known issue matching your symptoms.

Before installing new hardware that requires it. A newer processor frequently needs a firmware update applied first, using the old processor. Fitting it before updating produces a system that will not start and cannot be updated. Our processor guide covers this.

Before deploying a new operating system version, where the compatibility list specifies a minimum firmware level.

When to leave it alone

Being honest about this matters, because reflexive updating causes outages.

A stable system running a validated combination, with no symptoms and no applicable security issue, is not obviously improved by updating. The risk of the update process exceeds the benefit of being current.

This applies most strongly to end-of-life platforms, where an unrecoverable failure means sourcing a replacement board from a thinning market. On hardware you cannot easily replace, the calculus shifts considerably toward leaving working systems alone.

The useful question is not "is there a newer version" but "what does this version fix that affects me".

Order matters

Where multiple components need updating, sequence is not arbitrary.

Vendors frequently publish a recommended order, and where they do, follow it. The general pattern is management controller first, then system firmware, then storage controllers and adapters — because the management controller is often what applies the rest.

Two specifics worth knowing.

Storage controller firmware and driver are a matched pair. Updating one without the other on a virtualisation host is a common cause of subsequent instability.

Drive firmware exists too. It is rarely updated and occasionally matters, particularly where a known issue affects a specific model in arrays.

Doing it safely

The precautions that turn a risky operation into a routine one.

Verify backups restore first. Not that the job ran — that a restore works. Our backup guide covers why this distinction matters.

Ensure stable power. An interruption mid-update is the classic way to destroy a device. A UPS is doing real work here.

Read the release notes properly, including prerequisites and any minimum intermediate version. Some updates cannot be applied directly from older versions.

Record the current versions before starting, so you know what you had.

Do one system first and let it run for a period before the rest. This is the single most valuable practice, and it is what turns a fleet-wide outage into one machine with a problem.

Have out-of-band access available. If a firmware update leaves a device unreachable over the network, console access is how you find out why.

Fleet consistency

Worth aiming for, because inconsistency creates its own problems.

A fleet running several firmware versions behaves inconsistently, which makes troubleshooting considerably harder — a problem on one machine and not another may be firmware or may be something else, and you cannot tell.

It also complicates spares. A replacement part arriving at a different firmware level than the array or system expects can behave unexpectedly.

The practical approach: standardise on a version you have validated, apply it across the fleet in stages, and record it. Being consistently one version behind current is frequently better than being scattered across four.

Record what you run

Small effort, disproportionate value.

Keep a record of firmware versions per system and per component, updated when you change them. Three reasons: it tells you whether you are in a tested configuration when something misbehaves; it makes support conversations faster; and it means a replacement part can be brought to the matching level before it goes into an array.

This belongs with your asset records rather than in someone’s memory.

Common questions

On end-of-life platforms, weigh an unrecoverable update failure against a thinning replacement market before updating working systems.