Preserve, repair or replace yacht AV/IT equipment?

Begin with the service, not the equipment age

An older device can remain a sensible part of a stable system. A newer device can still be the wrong dependency if its configuration cannot be recovered, its external service has changed or it does not interoperate with retained equipment.

Define what the vessel needs the service to do, who is affected by failure and what evidence describes the current fault. This separates a lifecycle decision from a general preference for newer hardware.

When preservation is defensible

Preservation is reasonable when the equipment performs the required function, its failure behaviour is understood, configuration can be recovered and the surrounding system does not require an incompatible change.

Preservation may still require work: cleaning and thermal correction, verified backups, a spare strategy, documentation or removal of an unnecessary external dependency. Keeping equipment should be an active decision with a known operating boundary.

• Required service remains reliable in normal operation
• Configuration and recovery information are available
• Critical spares or a practical replacement route exist
• Security and vendor-support limitations are understood
• Retention does not block a required integration change

When repair is the better bounded scope

Repair fits a local, diagnosable defect where the surrounding platform remains supportable. Power supplies, storage, cooling, cabling, connectors and individual endpoints can fail without making the entire system obsolete.

The proposal should state what will be repaired, what evidence supports that boundary, how the result will be tested and what condition would stop the repair in favour of replacement. This avoids spending the work window repeatedly treating symptoms.

When replacement becomes necessary

Replacement is justified when the required service cannot be recovered reliably, critical parts or licensing are unavailable, the platform creates an unacceptable access risk, configuration cannot be retained, or compatibility prevents a necessary system change.

A replacement scope must include dependencies that are easy to overlook: power, cooling, rack space, network policy, storage, control interfaces, licences, user devices and retained endpoints. The acceptance test should describe normal operation from the crew or guest perspective, not only successful device startup.

Leave a decision record

Record the observed condition, options considered, assumptions, accepted risk and reason for the selected route. Where replacement is deferred, document the trigger that should reopen the decision. Where replacement proceeds, retain relevant configuration and a recovery route until the new service is accepted.

This creates a lifecycle decision that another engineer or technical manager can understand later without repeating the original investigation.