The B-2 Spirit was designed in the late 1970s and early 1980s. Its core mission computer architecture, its avionics software frameworks, and several of its fundamental systems were written in programming languages and on hardware platforms that are now decades obsolete. Updating them is not a matter of installing new software. It means recertifying every system that touches them, rewriting millions of lines of code, and retesting the entire aircraft from scratch — a process so expensive that the Air Force has repeatedly chosen to maintain legacy systems rather than modernise them.

The B-2's mission computing systems were designed in the late 1970s and early 1980s, when the aircraft programme began. The primary programming language used in early B-2 avionics software was Ada — a language developed for the US Department of Defense and widely used in military aviation of that era. The hardware ran on processors that were state of the art in the Reagan administration. Some of these foundational systems have been upgraded over the decades. Others remain in their original or near-original form because the cost and risk of replacing them has consistently outweighed the operational benefit.

In the commercial world, software updates are routine. In certified military avionics, every change to software — however small — triggers a recertification requirement. The aircraft's avionics certification establishes that the software behaves exactly as intended across every operational scenario. Change the software and the certification is no longer valid. The entire testing programme must be repeated for the affected systems, including integration testing across every system that interacts with the modified software. For a system as complex as the B-2's mission computer, a significant software update can require years of testing and cost hundreds of millions of dollars.

Some of the B-2's avionics hardware runs on components that are no longer manufactured. The processors, memory chips, and circuit boards used in 1980s military avionics were produced by companies that no longer exist, using fabrication processes that are no longer in use. The Air Force maintains stockpiles of spare components and, in some cases, has contracts with specialised manufacturers to produce small quantities of obsolete parts. When a component fails and the stockpile is exhausted, the alternative is either a major avionics redesign or cannibalising parts from other aircraft — neither of which is cheap or fast.

The Air Force has launched multiple B-2 avionics modernisation programmes over the aircraft's service life. Some have been completed successfully — the Extremely High Frequency satellite communications system, updated radar modes, improved defensive systems. Others have been reduced in scope or cancelled when cost estimates grew. The challenge is not just the cost of the modernisation itself but the cascade of testing and recertification requirements that follow any significant change to a complex integrated system. Each modernisation creates a new version of the aircraft that must be validated as a complete system.

Maintaining a fleet of 20 aircraft that uses components from suppliers who may no longer exist, in quantities too small to sustain a commercial production line, is a procurement challenge unlike any other in military aviation. The Air Force manages the B-2's parts supply through a combination of long-term contracts with specialised suppliers, strategic stockpiling of critical components, and in some cases, redesigning systems to use modern equivalent parts — which, again, triggers recertification requirements. The parts problem grows more acute each year as the gap between the B-2's design era and the present widens.

B-2 crews operate with displays and interfaces designed decades ago. The cockpit has been updated over the years, but some of the underlying systems those displays represent are operating on 1980s logic. Pilots describe the experience of flying modern missions with legacy systems as navigating a gap between what the aircraft can physically do and what its computers were designed to manage. Workarounds, procedural patches, and crew training compensate for system limitations that cannot be economically fixed. The crews are, in part, the human interface layer between a 21st-century mission and a 20th-century computer.

The B-21 Raider was designed explicitly with software modernisation in mind. Its open architecture avionics framework allows individual systems to be updated, replaced, or upgraded without triggering full recertification of every connected system — an approach borrowed from commercial aviation's more modular avionics philosophy. The B-21 is designed to be current at all times by design, not to be periodically modernised at enormous cost. The B-2's legacy software problem is not a failure of the engineers who designed it in the 1980s. It reflects a design philosophy that was standard at the time and that the B-21 was specifically designed to leave behind.