Why you can’t engineer your way out of Legacy
The Myth of “One Last Redesign”
Application OEMs often fall into a familiar trap: when legacy pressure builds, the next redesign is expected to solve it. One more refresh. One more board update. Another attempt to buy ten more years of support.
On paper, it feels rational. Engineering is engaged. Specifications are modernized. A technical path forward exists.
But for longlifecycle systems, redesign rarely removes the legacy problem. More often, it resets the clock while increasing exposure—schedule risk, parallel baselines, and lifecycle cost—introducing new qualification risk, expanding the number of configurations in the field, and leaving the underlying sustainment challenge unresolved.
The issue isn’t that redesigns are wrong. It’s the belief that engineering alone can compensate for the realities of longterm sustainment.
Why Redesign Alone Fails to Solve Legacy
- Your New Design Already has Obsolescence: Even the best redesign can’t stop suppliers from exiting markets, components from going endoflife, or manufacturing volumes from shrinking. In many programs, systems spend five years or more moving into initial production—often relying on components that are already obsolete by the time the first unit ships.
The result is that new designs inherit supplychain risk from day one. Sourcing becomes constrained earlier than planned, support costs rise before production ever stabilizes, and longterm availability questions surface almost immediately. Rather than resolving sustainment challenges, redesign simply pushes them into the next configuration—often with greater cost and customer dissatisfaction.
- The Redesign Plan Often Takes Longer: New hardware requires new design and requalification, updated documentation and training, and operational acceptance. These activities routinely take longer than planned, extending redesign timelines by years. During this period, the existing system must continue to be supported with declining part availability, increasing repair pressure, and growing uncertainty around delivery schedules and longterm support. While attention is focused on the redesign, sustainment issues persist—leading to systems down, multiplied pressure on the installed base, and teams effectively fighting two fires at once: managing legacy availability risk while attempting to bring the redesign online.
- Legacy Doesn’t Disappear: Fielded units remain in service long after a redesign is released. Entire fleets can’t be replaced overnight. The result is two active baselines—legacy and redesigned—each carrying its own obsolescence risk, effectively doubling the sustainment surface area. Supporting both in parallel increases configuration complexity, operational overhead, and lifecycle cost, while forcing teams to manage supplychain exposure, test capability, and parts availability across multiple generations for far longer than originally planned.
- Redesigns Don’t Create More Demand: Redesigns don’t change the economics of lowvolume support because they rarely represent a new program or a new market. In most cases, a redesign exists only to replace a portion of the existing installed base—the minimum required to keep the overall fleet operational.
That means demand remains limited, fragmented, and tied to legacy platforms. There is no surge in volume to offset NRE, test overhead, or sustainment complexity. Instead, organizations invest heavily to support aging technology that is not attractive to new platforms, while continuing to manage the same lowvolume realities. More effort is spent sustaining a shrinking population of systems, with fewer opportunities to recover cost or reduce longterm exposure.
When a Redesign Decision Is Really a Sustainment Problem
When a product has a 30year mission life, but supply chains, engineering teams, and institutional knowledge rotate every three to five years, the limiting factor isn’t the electrical design. It’s the ability to sustain what’s already been built.
Sustainment requires a different mindset than redesign. It prioritizes continuity over optimization, repeatability over novelty, and historical performance over ideal specifications. Without dedicated sustainment processes, organizations default to using redesign as a proxy for support—rediscovering problems they’ve already solved, often under pressure and at higher cost.
What Sustainers Understand That Designers Often Don’t
This isn’t a critique of design teams or engineering capability—it reflects an organizational reality where different functions are optimized for different objectives.
Designers build what’s next. Sustainers keep what exists working.
That means:
- Managing obsolete parts without forcing redesigns
- Maintaining institutional knowledge as engineers, suppliers, and programs change
- Preserving legacy test equipment, fixtures, and acceptance methods tied to historical baselines—not just data sheets
- Capturing data from the fleet on operational reality, not just what the specification intended
- Supporting lowvolume reality instead of highvolume assumptions
It’s a different discipline, with different people, tools, metrics, and success criteria. Treating sustainment as an extension of engineering inevitably leads to distraction, delay, and repeated risk.
Planning for Legacy Instead of Chasing It
At this point, the question is no longer operational—it’s a leadership decision about how risk, resources, and responsibility are managed over the life of the system.
Organizations that manage legacy systems effectively stop treating redesign as the default response to obsolescence. Instead, they build sustainment strategies that operate alongside engineering—not beneath it.
That includes:
- Authorized manufacturing and repair paths for legacy hardware
- Preservation of test capability, documentation, and configuration knowledge
- Supplychain strategies designed for long lifecycles and low volumes
- Partners focused specifically on sustaining installed systems
GDCA enables this approach by helping customers establish controlled, authorized sustainment paths—so legacy systems remain supported without forcing repeated redesign cycles or consuming engineering capacity.
Final Thought
Redesign can change the hardware, but it doesn’t resolve the underlying realities of longterm support. When redesign is used as a substitute for sustainment, organizations inherit longer timelines, higher costs, and parallel obsolescence risk across multiple baselines.
The more durable path is to treat sustainment as its own discipline—one that operates alongside engineering and protects the installed base while new designs evolve.
GDCA helps organizations build controlled, authorized sustainment strategies that reduce redesign pressure, stabilize longlifecycle programs, and keep engineering focused on what comes next—without leaving legacy systems exposed.
_________
|
|
Thomas Helmonds, Solution Director THelmonds@gdca.com |
