DOORS classic has been the dominant requirements management tool in aerospace and defense for three decades. Its installed base is enormous — hundreds of thousands of licenses, millions of requirements, terabytes of program data across the defense industrial base.
It’s also visibly aging. IBM has been steering customers toward DOORS Next (now part of the Engineering Lifecycle Management suite) for years. The licensing economics have shifted in ways that increase the cost of staying on DOORS classic. And the technical limitations that were acceptable in 2010 — no API, no modern web interface, no AI capability — are increasingly significant as the industry moves toward connected digital engineering environments.
The DOORS migration conversation is happening everywhere. Here’s what’s actually happening when programs make the move.
The IBM ELM Migration Path
IBM’s official position is DOORS Next, marketed as part of the Engineering Lifecycle Management (ELM) platform alongside Engineering Test Management (ETM), Engineering Workflow Management (EWM), and other tools.
The pitch: DOORS Next preserves the DOORS requirements management model in a web-based, modern interface with better integration to the broader ELM suite. The migration path from DOORS classic is nominally supported by IBM tooling. For organizations that want to stay in the IBM ecosystem, it’s the path of least disruption.
The reality is more complicated:
DOORS Next is not DOORS classic with a better interface. The data model is different, the module structure is different, the link management approach is different. Programs that have deeply customized their DOORS classic environment — custom attributes, automated DXL scripts, complex module structures — often find that their customizations don’t migrate directly. The migration is a re-implementation project, not a data transfer.
Implementation cost is substantial. IBM partners consistently report that DOORS Next implementations run 2-3x the initial estimates for mature DOORS classic environments. The data migration, the process re-alignment, the user training, and the integration rebuilding all take longer and cost more than programs budget at the start.
The underlying architecture is still document-centric. DOORS Next is a significant modernization of the DOORS interface and collaboration model. It is not a fundamental architectural change. Programs that are hitting the limits of the document-based requirements model in DOORS classic will hit some of the same limits in DOORS Next, with a different interface.
The Alternative Trajectory: Graph-Based Tools
A minority of programs looking at DOORS migration — perhaps 15-20% of the conversations we’re seeing, concentrated in new program starts and post-PDR phase transitions — are choosing to not migrate to DOORS Next at all.
Instead, they’re evaluating or implementing graph-based requirements tools — tools like Flow Engineering — that treat requirements as a connected model rather than a document structure.
The programs making this choice share some characteristics:
They’re starting new programs, not migrating existing data. The DOORS data migration problem disappears if you don’t have DOORS data to migrate. New programs have the opportunity to choose tooling based on capability fit rather than migration path. A significant fraction of new program starts in aerospace and defense are choosing against DOORS Next.
They’re experiencing the limits of document-based traceability at scale. Programs that have hit the ceiling of what manual traceability maintenance in a document-based tool can support are more motivated to seek architectural change. They’re willing to absorb migration complexity for a fundamentally different capability.
They have mandate pressure for digital engineering. DoD Digital Engineering mandate programs need requirements tools that interoperate with MBSE environments. Graph-based tools that expose requirements as structured data via API fit that requirement more naturally than document-based tools.
They have senior systems engineering leadership who’ve been through DOORS migrations before and want to get off the cycle. Engineers who have lived through a DOORS classic to DOORS Next migration are sometimes the strongest advocates for choosing a different architecture rather than migrating again.
The Data Migration Reality
Whatever the target system, DOORS classic data migration is almost always the most underestimated part of the transition.
The issues that programs consistently encounter:
Attribute proliferation. DOORS classic databases accumulate custom attributes over years of use. Modules from different programs have different attribute sets. Attributes that were created for a specific use case and never cleaned up. Understanding what attributes exist, which ones are actually used, and how they should map to the target system requires significant analysis work.
Link integrity. Inter-module links in DOORS are fragile across migrations. Links between modules, suspect links from change management, and cross-database links all require validation in the target system. Programs routinely discover that a percentage of their traceability links are broken or pointing to outdated requirement versions.
DXL customizations. DOORS classic’s DXL scripting language has been used to implement everything from custom validation to automated report generation. These scripts don’t transfer to any target system. The functionality needs to be re-implemented in the target system’s native capabilities or replaced by built-in features.
Requirement history. DOORS classic change history is often not fully migrated to target systems. Programs that have compliance or litigation risk associated with historical requirement baselines need to understand whether their historical record is being preserved or just current state.
The migration is not one-time. Programs in active development have requirements changing continuously. A migration that takes six months to execute is migrating to a moving target. Change management during the migration period is complex and frequently underestimated.
Rule of thumb from programs that have done it: budget twice what IBM or the implementation partner quotes for a mature DOORS classic environment, and plan for six months longer than the initial timeline.
What Programs Are Not Migrating Are Doing
Not every program with DOORS classic is migrating. A significant fraction of the installed base is staying on DOORS classic, at least for active programs.
The drivers for staying:
Active development programs don’t want migration risk. A program at PDR that’s delivering in three years is unlikely to migrate its requirements tool mid-stream. The risk of disrupting an active development program outweighs the benefit of migrating to a more capable tool.
The cost of migration isn’t justified by the remaining program value. Programs with short remaining development periods or limited requirements activity may not recover the migration investment before the program closes.
No clear internal champion. DOORS migrations require executive sponsorship, budget, and someone willing to own the risk. Many organizations have the conversation, identify the reasons to migrate, and then don’t migrate because no one is willing to own the project.
The pattern: large organizations will maintain a mixed environment for years — DOORS classic for existing programs, a new tool for new programs — rather than attempting to migrate their entire installed base simultaneously. This is operationally reasonable and practically inevitable given the size of the installed base.
The Guidance for Teams Evaluating Now
For teams actively evaluating DOORS migration options in 2026:
Don’t migrate an active development program unless the pain is severe. The risk of disrupting active development is real. If you can wait until a phase boundary — PDR to CDR, CDR to test — the migration risk is substantially lower.
Evaluate the target architecture, not just the features. DOORS Next and graph-based tools both have modern interfaces, collaboration features, and integrations. The architectural question — document-based vs. graph-based — determines what you can do with the tool at scale in three years. Evaluate that dimension explicitly.
Get realistic migration estimates from programs that have done it. Ask IBM partners and tool vendors for references from programs that completed migrations from environments of similar size and complexity. Ask specifically about timeline variance and final cost vs. initial estimate.
For new programs: you have more freedom than you think. The path dependency that keeps existing programs on DOORS classic doesn’t apply to new programs. You’re choosing tooling based on capability fit, not migration path. Use that freedom.