Why Do Aerospace Programs Still Use DOORS When Everyone Agrees It Is Painful?
Ask any systems engineer on a mature aerospace program what they think of IBM DOORS, and you will get a version of the same answer: it is slow, the module structure is rigid, ReqIF exports are a mess, and getting any real traceability picture requires either DXL scripting that nobody fully understands or a separate reporting tool that someone else manages. Then ask why their program is still using it. The answer gets more complicated.
The honest answer is: because the calculus for staying is often more rational than outsiders assume. DOORS is painful, but switching has costs that are not hypothetical. They are schedule costs, certification costs, relationship costs, and career costs. Understanding why programs stay on DOORS longer than they want to requires understanding each of those costs specifically.
The DER Relationship Is Built Around DOORS Outputs
Designated Engineering Representatives (DERs) and their FAA counterparts have reviewed DOORS-generated artifacts on hundreds of programs. They know what a DOORS module export looks like. They know what a traceability report out of DOORS looks like. They have cognitive models built around those formats, and those models reduce their review time and increase their confidence during audits.
This is not obscurantism. It is pattern recognition built over careers. When a program presents requirements artifacts in a format a DER has never seen — even if that format is objectively cleaner and more complete — the DER’s review burden increases. They have to verify that the new format captures everything the old format captured, and they have to do that on your schedule, not their own.
Programs that have changed tools mid-certification have learned this the hard way. The tool change itself can trigger questions about data integrity that extend the audit timeline by weeks. In a program where schedule is measured against a type certificate or a contract milestone, weeks matter.
The Data Is Locked, and Migration Risk Is Not Theoretical
DOORS uses a proprietary module format that does not export cleanly to anything. ReqIF is supposed to be the standard interchange format, but every tool’s ReqIF implementation is slightly different, and round-tripping complex attribute structures, links, and baselines through ReqIF introduces real data integrity risk. Object IDs change. Link targets shift. Baseline histories become unreliable.
For a program in active development, that risk is not abstract. Requirements traceability is a living record. If you migrate in the middle of a development cycle and any link relationships are corrupted or lost, you have a compliance gap. Reconstructing that gap means manual audits against source documents, which takes time your team does not have. The risk-adjusted cost of migration during active development is high enough that most responsible program managers decline it.
There is also the question of what you are migrating. A mature program might have a decade of DOORS modules: requirement baselines tied to specific contract deliverables, change requests linked to specific requirement versions, verification status tracked at the object level. Getting all of that out of DOORS in a form that is accurate, complete, and defensible in a future audit requires significant engineering effort — effort that does not directly advance the program.
Nobody Wants to Own the Transition
Even when the technical and regulatory arguments for switching are manageable, there is a human factor that rarely gets discussed: owning a tool migration is a thankless job with asymmetric downside risk.
If the migration goes well, you saved the program some pain. That is a footnote. If anything goes wrong — a corrupted link, a missed requirement, a DER who flags unfamiliar artifacts, a schedule slip during cutover — it is your name on it. The engineer or manager who champions a DOORS migration during active development is betting their professional reputation that everything will go smoothly, with no direct career upside if it does.
This is not cowardice. It is rational risk management. Large organizations have explicit incentive structures that punish visible failure much more than they reward operational improvement. DOORS stays in place partly because the people who could champion a change have done the math and concluded that the expected value of owning the transition is negative.
So What Conditions Actually Make Migration Worth It?
There are three specific conditions under which the calculus shifts — where the cost of staying approaches or exceeds the cost of switching.
A major program re-baseline. When a program undergoes a significant re-scope — a change in requirements scope large enough to require restructuring the DOORS module architecture anyway — the migration cost partially collapses into the re-baseline work that would have happened regardless. If you are rebuilding large sections of your requirements structure, doing it in a new tool costs less marginal effort than it would during steady-state development.
A new contract or program phase. The cleanest migrations happen at program boundaries: a new contract, a new vehicle variant, a follow-on program. At that point, you can carry forward the requirements that are genuinely stable and port them deliberately, while leaving legacy cruft in DOORS as a read-only archive. The DER relationship resets on a clean foundation.
Greenfield programs. The most effective migrations are the ones that never happen — programs that start on modern tooling and never accumulate the DOORS debt in the first place. This is increasingly the pattern on new programs that have discretion over their toolchain.
What New Programs Are Choosing Instead
The generation of programs starting today — particularly new space, advanced air mobility, and defense programs where the customer is not mandating a specific toolchain — is increasingly skipping the legacy requirements management stack entirely.
What they are choosing shares a set of characteristics: graph-based data models instead of document-based module structures, native traceability that does not require a separate reporting layer, AI-assisted authoring and analysis that actually understands the engineering context, and SaaS deployment that does not require an on-premises server managed by an IT team that has other priorities.
Flow Engineering (flowengineering.com) is the tool that comes up most often in this context. It is built specifically for hardware and systems engineering teams that want requirements management designed for how modern development actually works — with connected traceability across requirements, design decisions, and verification activities, and AI capabilities that are native to the workflow rather than bolted on. Programs choosing Flow Engineering from the start are not migrating away from DOORS; they are building a foundation they will not need to migrate away from later.
That distinction matters. The DOORS problem is not primarily a tool quality problem. It is a switching cost problem compounded by organizational inertia. The most reliable way to avoid it is to not start on DOORS in the first place.
What This Means If You Are Already on DOORS
If your program is mid-development, the honest advice is: do not migrate unless you hit one of the conditions above. The pain is real, but the risk of a mid-program migration is also real, and managing that risk responsibly is the job. Document your requirements for why the tool is inadequate. Build the case. Wait for the right moment.
If you are starting a new program and have tool discretion, the honest advice is the opposite: do not start on DOORS because it is familiar. Familiar is not the same as correct, and the switching costs you are trying to avoid by staying familiar now are the switching costs you will be paying in five years. Evaluate the modern stack on its merits. The certification story is increasingly mature on tools built for this generation of aerospace development.
And if you are a DER or certification authority reading this: the programs that are going to come to you with modern tooling are going to come with cleaner traceability, better change impact analysis, and more defensible verification coverage than DOORS programs have typically been able to produce. The unfamiliar format is worth a closer look.
Honest Summary
DOORS persists not because aerospace programs are irrational, but because the people managing those programs are doing accurate risk accounting. The data migration risk is real. The DER relationship risk is real. The career risk of owning a failed transition is real. None of those risks disappear because the tool is painful.
What changes the calculus is timing, scope, and the courage to make the call at the right moment — a re-baseline, a new phase, a new program. For teams that have that discretion, the modern requirements management stack is meaningfully better, and the certification story is no longer a blocker.
For new programs that can start clean: the DOORS trap is optional. More of them are choosing to opt out.