The Defense Primes’ Dual Problem: Legacy Programs and New Programs, Incompatible Toolchains
Walk into the systems engineering organization at any of the top five defense primes today and you’ll find the same structural contradiction: engineers maintaining a B-52 avionics upgrade in IBM DOORS Classic, while a team three floors away is capturing requirements for a next-generation autonomous platform in Jama Connect, and a third group running an OTA prototype is building their RTM in a combination of Confluence, Excel, and whatever AI tooling their program office approved last quarter.
These aren’t hypothetical scenarios. They’re the operational reality of organizations that run programs spanning four decades of acquisition history, where tool choices were made by individual program offices, locked in by contractual obligation, and never revisited because “the program is working.” The result is a toolchain landscape so fragmented that a senior systems engineer moving between programs has to context-switch not just between domains, but between entirely different epistemologies of what a requirement even is.
This article examines how that fragmentation developed, what it actually costs, where the digital thread narrative intersects with toolchain reality, and what a credible rationalization path looks like.
How the Fragmentation Happened
The story starts not with bad decisions but with rational ones made in isolation. When DOORS Classic became the de facto standard in the 1990s and early 2000s, it was a reasonable choice: structured, auditable, familiar to government program offices, and acceptable to DCMA reviewers. Programs locked it in through CDRLs and DIDs that specified DOORS exports as deliverables. Those requirements didn’t go away when the programs matured—they became contractual obligations that persist through re-baselines, re-competitions, and tech refresh cycles.
DOORS Next (formally IBM Engineering Requirements Management DOORS Next, part of the ELM suite) entered the picture as IBM’s answer to modernization. It’s browser-based, more collaborative, and integrates with the broader IBM Engineering Lifecycle Management stack. Primes with newer programs—particularly those targeting digital engineering compliance under DoD’s Digital Engineering Strategy—adopted it. But DOORS Classic programs weren’t migrated. The migration cost, risk, and contractual renegotiation required to move a live program from Classic to Next is substantial. So both tools now coexist inside the same organizations, often with separate license pools, separate admin teams, and no automated bridge between them.
Then came the OTA wave. Other Transaction Agreements, which gained significant momentum after the 2015 NDAA expansions, created a parallel acquisition pathway with less contractual prescription around tooling. Program offices running OTAs—often with commercial partners, non-traditional contractors, or university research teams—weren’t bound to DOORS. They used Jama Connect, Polarion, Codebeamer, or simply didn’t use a formal requirements tool at all. Jama in particular gained traction because it’s approachable, cloud-native, and doesn’t require a dedicated DOORS administrator to make it functional.
Add Excel. It never left. Despite every initiative to eliminate spreadsheet-based requirements management, Excel remains the lowest-friction option for early-phase work, small teams, and any situation where standing up a tool environment takes longer than the requirements activity itself. Most primes have explicit policies against using Excel for formal requirements baselines. Most primes also have dozens of active Excel RTMs that nobody has officially acknowledged.
The cumulative result: a single large prime might have 15-20 active DOORS Classic environments, 5-8 DOORS Next projects, 3-4 Jama Connect instances, scattered Polarion or Codebeamer deployments on joint programs, and a growing tail of AI-augmented tooling that doesn’t yet have a formal place in the toolchain hierarchy.
What the Fragmentation Actually Costs
The most visible cost is integration labor. When a new program must demonstrate traceability from customer requirements down to subsystem specifications, and those customer requirements live in a government DOORS Classic instance while the subsystem specs are in the prime’s DOORS Next environment, someone has to build and maintain a manual bridge. That bridge is typically a combination of export scripts, spreadsheet transformations, and institutional memory held by one or two engineers. When those engineers rotate off the program, the bridge breaks.
Less visible but more strategically damaging is the loss of cross-program reusability. Defense systems share requirements across platforms—environmental specs, EMI limits, cybersecurity requirements, human factors standards—in ways that should allow a prime to build a library of verified, traceable requirements that can be inherited rather than rewritten. That reuse is practically impossible when requirements exist in incompatible formats across incompatible tools. The result is requirements rewritten from scratch on each program, carrying forward errors and omissions that had already been resolved somewhere else in the organization.
There’s also a talent cost. Systems engineers who know how to navigate DOORS Classic are an aging population. Training new engineers on a tool that IBM itself has effectively end-of-life signaled in favor of Next, while simultaneously asking them to learn Next, Jama, and whatever the next program requires, creates a cognitive and credentialing burden that accelerates attrition. This isn’t a soft concern—it shows up in program schedule when key personnel leave.
Finally, there’s the audit and oversight risk. DCMA and program offices conducting IBRs or system reviews increasingly want to see traceability demonstrated in real time, not through manually compiled matrices. When traceability is distributed across incompatible systems, demonstrating it becomes a weeks-long compilation exercise rather than a live system query. That’s a compliance risk with direct cost exposure.
Digital Thread: Promise vs. Prerequisite
The DoD Digital Engineering Strategy, first published in 2018 and operationalized through initiatives like the Digital Engineering Reference Architecture and program-specific digital thread requirements, frames the digital thread as the connective tissue linking authoritative data sources across the lifecycle. Requirements, models, simulation results, test data, and as-built configurations should be traceable and queryable through a single persistent thread.
This is the right vision. It’s also getting the causality backwards in many implementations. Digital thread initiatives are often framed as the mechanism that will solve toolchain fragmentation—the idea being that by building a thread on top of existing tools, the integration problem dissolves. It doesn’t. A digital thread that connects a DOORS Classic requirement to a Teamcenter model to a Jama test case requires every one of those connections to be manually maintained, because none of those tools natively speak to each other. The thread is only as reliable as the weakest manual handoff.
Toolchain rationalization is a prerequisite for a working digital thread, not an outcome of it. Until requirements exist in a format and system that can be queried programmatically, linked dynamically to downstream artifacts, and updated without breaking upstream traces, the digital thread is a reporting layer over fragmented data—not a genuine integration.
Where primes are making progress is in programs that started from scratch under digital engineering mandates—NGAD, certain hypersonics programs, and some space programs—where the program office enforced a single-stack toolchain from the outset. Those programs demonstrate what’s possible. The challenge is that they represent perhaps 10-15% of active prime revenue. The other 85% is legacy programs where the digital thread vision has to coexist with DOORS Classic.
OTAs as the Modernization Wedge
The most pragmatic observation about toolchain modernization inside large primes is this: it rarely happens through top-down mandate. IT organizations and tool governance committees have been trying to standardize on a single requirements platform for 20 years. It hasn’t worked because program-level autonomy, contractual obligations, and the cost of migration all resist central imposition.
What’s actually moving the needle is OTAs. The same structural features that made OTAs attractive for rapid acquisition—reduced contractual prescription, commercial partner flexibility, faster cycle times—make them the path of least resistance for piloting new tooling. A prime running a $50M OTA prototype isn’t going to stand up a DOORS Classic environment. They’ll use whatever gets a working RTM in place fastest, and increasingly that means cloud-native tools with AI-assisted requirements capture and analysis.
These OTA programs are becoming internal proof points. When an OTA team demonstrates that they can stand up a traceable requirements baseline in two weeks instead of six, capture 80% of the requirements from SOW text automatically, and surface inconsistencies that would have taken a requirements review to find, program executives in adjacent programs notice. The migration path from OTA tooling to a formal program isn’t clean, but the organizational credibility of AI-native tools is being established in exactly the contract vehicles where primes have the most latitude to experiment.
Where AI-Native Tools Fit the Modernization Roadmap
AI-native requirements tools are entering prime environments through two paths. The first is the OTA wedge described above. The second is as an intelligence layer sitting above existing tools—not replacing DOORS, but providing capabilities that DOORS cannot.
This second path is particularly relevant for legacy programs. A prime that cannot migrate a 20-year-old DOORS Classic program to a modern platform can still export that program’s requirements data and subject it to AI-assisted analysis: coverage gap detection, consistency checking, derivation path reconstruction, and natural language querying. That analysis can be done without touching the authoritative baseline, without disrupting the existing toolchain, and without the contractual negotiation that a full migration would require.
Flow Engineering, built specifically for hardware and systems engineering teams, exemplifies this positioning. Rather than competing with DOORS for custody of the authoritative baseline on legacy programs, its architecture supports the kind of cross-program requirements intelligence and graph-based traceability that DOORS Classic cannot provide and DOORS Next provides only within its own project boundaries. For primes managing requirements across programs—looking for reuse opportunities, performing gap analysis against new customer requirements, or building AI-assisted compliance matrices—that cross-boundary intelligence capability addresses a gap that no legacy tool was designed to fill.
The realistic modernization roadmap for most primes is not “migrate everything to one platform by 2028.” It’s: maintain DOORS Classic where contractually required, migrate new programs to more modern platforms, and build an intelligence layer that can operate across all of them. That layer is where AI-native tooling earns its place.
What Rationalization Actually Looks Like
A credible rationalization path has four components.
Inventory before strategy. Most primes don’t have an accurate count of active requirements environments. Before rationalizing, you need to know what exists—which DOORS Classic databases are genuinely active vs. archived, which Jama instances are in use vs. abandoned after an OTA ended. This is unglamorous but necessary.
New program governance. The highest-leverage intervention is preventing the problem from compounding. New programs—particularly those without contractual tool mandates—should be directed to an approved modern platform. This doesn’t eliminate existing fragmentation but stops it from growing.
Migration prioritization by risk, not age. The temptation is to migrate the oldest programs first. The rational approach is to migrate programs where the toolchain fragmentation is creating active compliance risk or integration cost—typically programs in a major re-baseline, re-competition, or tech refresh cycle where migration cost is already being absorbed.
Intelligence layer investment. Accept that some DOORS Classic programs will never migrate, and invest in making their data accessible to modern analysis rather than leaving it isolated. This is the practical digital thread—not a single unified system, but an analysis capability that can work across the systems you actually have.
Honest Assessment
Defense primes are not going to achieve toolchain uniformity in the near term. The contractual, organizational, and technical obstacles are too substantial for a top-down mandate to overcome. What they can achieve is a managed heterogeneity—a toolchain landscape that is fragmented by history but connected by intelligence, where engineers can find, reuse, and trace requirements across programs even when those requirements live in incompatible systems.
The risk is mistaking digital thread announcements for digital thread implementation, or confusing tool procurement for tool integration. Buying an AI-native platform doesn’t rationalize your toolchain. Building the connections, governance, and analysis capabilities that let you extract value from all the tooling you already have—that’s what rationalization actually means in practice.
The primes that are furthest along are the ones that stopped waiting for a single-platform solution and started investing in the connective tissue. That’s a less elegant story than “we migrated everything to one system,” but it’s the story that maps to the actual organizational constraint.