Keeping Legacy UNIX Platforms Running: HP-UX and OpenVMS
Organisations still running HP-UX, OpenVMS and similar platforms are frequently assumed to be behind. Usually they have costed migration, understood the risk, and concluded that keeping the platform alive is the cheaper and safer option. That is a decision, not neglect — but it needs managing deliberately.
Why these systems stay in service
The applications running on them are typically decades old, deeply integrated, and doing something specific and critical — manufacturing control, financial processing, records systems, laboratory or process automation.
Three things make migration genuinely hard rather than merely inconvenient.
The source may be gone. Applications written decades ago by people who have left, sometimes with no maintained source code and no complete specification of what the system actually does.
Behaviour is the specification. Where documentation is incomplete, the system’s current behaviour is the only authoritative description of the business rules. Reimplementing it means rediscovering those rules, and the ones you miss surface later as incorrect results rather than errors.
Validation and certification. In regulated environments the system may be validated as it stands, and revalidating a replacement is a project in itself.
Against that, keeping a working platform running for a few more years is frequently the rational choice.
The real constraint is parts, not support
Manufacturer support ended long ago on most of these platforms, and it changed very little operationally.
What actually determines how long the platform survives is whether parts remain obtainable. Every unit in circulation came out of a system somewhere, and that pool shrinks over time. Our spares guide covers why this date is never announced and has to be watched.
The components that fail are predictable: drives first, then power supplies, then fans. Memory and processors rarely fail but are hard to replace when they do.
This is why the single most valuable action is knowing exactly what is fitted — pull a drive, read and photograph the part number and its carrier, record it. Our HP Integrity drive guide covers why Integrity part numbers differ from ProLiant ones, which is exactly the kind of distinction that causes wrong orders.
Hold spares, not a support contract
Where no support channel exists, the spares shelf is the support contract.
Hold drives matching what is fitted, by exact part number. These fail most often, and matching matters because carrier and firmware are encoded in the part number rather than the specification.
Hold a power supply per system type. Second most common failure, hot-swappable on most platforms, and model-specific. Our power supply guide covers why they are not generic.
Consider a complete spare system rather than component spares. On a platform this old it covers every failure mode rather than one, requires no disassembly under pressure, and is frequently obtainable for a comparable price to a few components. Our system board guide covers why component-level replacement is often the wrong answer here.
Buy now rather than planning to. On a thinning market, a spare bought today is materially different from one you intend to source when something fails.
Storage is the highest risk
Drives fail more than anything else, and legacy platforms make each failure worse.
Ageing arrays fail together. Drives installed at the same time share batch, conditions and hours, so when one reaches wear-out the others are at the same point. A rebuild then puts every survivor under sustained load, which is when second failures arrive. Our lifespan guide covers this.
Simple-swap bays extend the exposure. Where replacement requires powering down, the array runs degraded through the entire process of arranging a window, not just the swap. Double parity stops being an upgrade and becomes the sensible default — our RAID guide covers the trade-offs.
Fibre Channel shelves have their own behaviour: the arbitrated loop means one misbehaving drive can disrupt others, so several drives appearing troubled does not necessarily mean several failures.
And on any system this age, verify that backups actually restore. The probability of losing an array is materially higher than on current hardware.
Firmware: leave it alone unless there is a reason
The calculus differs from modern platforms.
On current hardware, a failed firmware update means sourcing a replacement board from an available market. On a legacy platform it may mean sourcing from a market that barely exists.
Unless there is a specific problem the update addresses, or a security issue that genuinely affects you, a stable system running a working combination is not obviously improved by updating. Our firmware guide covers when the case is clear.
Set a horizon rather than drifting
The point of managing a legacy platform well is not to keep it forever. It is to make the end a decision rather than an event.
Migrating while spares are still obtainable leaves you options — timing, budget cycle, phased cutover, proper testing, running both in parallel. Being forced into it by a failure you cannot source leaves an outage and whatever can be arranged in a hurry.
A yearly review is enough: what is still running, how thin is the parts market, what would migration cost, and what is the consequence of an unrecoverable failure. That hour is the difference between managing the platform and hoping.
Common questions
Why do organisations still run HP-UX or OpenVMS?
Because migration is genuinely hard: source code may be gone, the system’s behaviour is frequently the only complete specification of the business rules, and in regulated environments a replacement needs revalidating. Keeping a working platform running is often the rational choice.
What actually limits how long the platform survives?
Parts availability rather than support. Every unit in circulation came out of a system somewhere and the pool shrinks over time, and that date is never announced. Drives fail first, then power supplies, then fans.
Component spares or a complete spare system?
On a platform this old, a complete spare system is frequently better. It covers every failure mode rather than one, needs no disassembly under pressure, and is often obtainable for a comparable price to a few components.
Should I update firmware on a legacy system?
Only for a specific reason. A failed update on a current platform means sourcing a replacement board from an available market; on a legacy platform it may mean a market that barely exists. A stable working combination is not obviously improved by updating.
When should I migrate?
While spares are still obtainable, which leaves you options on timing, budget and testing. Being forced by a failure you cannot source leaves an outage and whatever can be arranged in a hurry.
We stock parts for HP Integrity and other legacy platforms — send us the part number from a fitted component and we will confirm availability.
