DOORS vs DOORS Next: what changed, and which should you use?

The short version

DOORS Classic and DOORS Next are two separate IBM products that solve the same core problem — requirements management at scale — with different architectural choices. Classic came first and has decades of program history behind it; Next was designed from scratch for the web era on IBM's Jazz platform. IBM publishes both and continues active development on both; neither product has been announced as end-of-life. If your program already runs on Classic and the DXL automation is working, there is no reason to migrate. If you are starting a new program or modernizing, DOORS Next is the forward-looking option.

DOORS Classic

IBM Engineering Requirements Management DOORS — referred to as “DOORS Classic” or the 9.x line — is a Windows desktop application backed by the DOORS database server. Requirements engineers work inside modules: structured documents that contain requirement objects, attributes, and tables. Automation runs through DXL (the DOORS eXtension Language), a scripting language purpose-built for the DOORS data model. Traceability is managed via links, linksets, and link modules that connect objects across modules.

Classic is overwhelmingly on-premise. Its strengths are deep customization through DXL, mature integration with existing program infrastructure, very large module support, and a large trained user base on established defense and aerospace programs.

DOORS Next (DNG)

IBM Engineering Requirements Management DOORS Next (DNG, or “DOORS Next”) is a browser application that runs on the Jazz Team Server, IBM's collaborative platform for the Engineering Lifecycle Management (ELM) suite. There is no DXL. All integration is through OSLC (Open Services for Lifecycle Collaboration) and REST APIs, which means DOORS Next links natively with EWM (Engineering Workflow Manager), ETM (Engineering Test Management), Rhapsody Model Manager, and other OSLC-capable tools in the ELM toolchain.

DOORS Next is deployable on-premise or as a hosted offering. IBM provides DOORS Next at no additional cost to customers with active subscription & support entitlements.

Data model differences

This is the most important technical difference to understand before any migration discussion.

In Classic, requirements are objects inside formal modules. Object IDs are module-scoped — an object exists in the context of its module. Traceability between modules is captured in link modules and linksets. The data lives in the DOORS database.

In DOORS Next, the primitive is a typed base artifact. Base artifacts are reusable — the same artifact can appear in multiple modules without being copied. This enables artifact reuse across projects, avoids duplication of requirements, and supports a cleaner separation between the artifact itself and its organization inside a particular module view. Linking is done via OSLC link types.

The practical implication: requirements analysts who move from Classic to Next need to internalize the artifact-vs-module distinction. Module views in DOORS Next look similar to Classic modules on the surface, but the underlying model — and what it means to “own” or “copy” a requirement — is different.

Configuration management

Configuration management is the feature that most sharply separates the two products.

Classic supports baselines at the module level. You can baseline a module and trace changes against it. There is no branching model, no concept of parallel streams, and no mechanism to tie module baselines across tools into a single cross-program configuration.

DOORS Next has a full configuration management model: components, streams, baselines, and change sets. It also integrates with Global Configuration Management (GCM) — an ELM service that ties configurations from DOORS Next, EWM, ETM, and Rhapsody Model Manager into a single global configuration. This is what makes program variants and parallel development streams tractable at scale. Configuration management in DOORS Next is opt-in and enabled per project; projects without CM enabled have a simpler flat model.

For programs with multiple variants, product lines, or parallel baselines — where Classic users typically resort to manual module copies and naming conventions — the DOORS Next CM model is a genuine architectural improvement.

Which should you use?

Favor DOORS Classic when:

• The program has a large, mature Classic database and years of accumulated DXL automation.
• Your team is highly trained on Classic and the requirements management process is stable.
• Your modules are very large (millions of objects) — Classic's performance profile at extreme scale is well-characterized.
• You have deep custom integrations that depend on the DXL API and no near-term capacity to re-implement them in REST.

Favor DOORS Next when:

• You are starting a new program and want a browser-based, collaborative workflow without a thick-client deployment dependency.
• Your program needs OSLC-native integration with EWM, ETM, or Rhapsody Model Manager — cross-tool traceability and global configurations.
• You are managing product lines or program variants that would benefit from configuration management with streams and change sets.
• Your organization is on IBM's ELM subscription and DOORS Next is already part of the entitlement.

On MBSE programs, both tools link to Cameo via Cameo DataHub. DOORS Next, being OSLC-native, supports richer live OSLC linking — see also requirements traceability in Cameo.

NOTEIBM lifecycle dates and product roadmaps change. Always verify current IBM support lifecycle pages before making a go/no-go migration decision based on end-of-support timing.

Migration path

IBM provides a supported migration path from Classic to DOORS Next. The migration covers modules, type definitions, attribute definitions, views, tables, and links. The effort scales with the size of the Classic database, the depth of DXL automation (which has no direct equivalent in DOORS Next), and the complexity of the link network.

Key migration considerations:

• DXL scripts do not migrate. Any automation logic in DXL must be re-evaluated and re-implemented using DOORS Next REST APIs or third-party tooling. This is typically the largest migration effort on programs with mature Classic customizations.
• The data model shift requires analyst retraining. The artifact-vs-module distinction in DOORS Next is not just a UI change — it changes how teams think about requirement ownership, reuse, and baseline scope.
• Configuration management is opt-in at project creation. Migrated projects should decide upfront whether to enable CM, because enabling it later on an active project is a significant operation.

FAQ