US: +1 (610) 247-9595 / EU: +48 666 74 71 74
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
ul. Antoniego Pajdaka 5/98
03-134 Warsaw, Poland
NIP : 8921405210
Regon : 146293701
Created by Quality Pixels | Privacy Policy
Migrated and validated · your teams keep working
IBM Engineering DOORS Next
We analyse your DOORS 9 databases, design the target model in DOORS Next and move your requirements in phases, so your links stay intact and your teams keep working during the move.
DOORS 9 to DOORS Next migrationOverview
DOORS 9 has carried requirements for safety-critical programs for decades, but it sits outside the IBM Engineering Lifecycle Management web platform. DOORS Next shares that platform with Test Management, Workflow Management and Rhapsody Model Manager, and it is where IBM delivers new capabilities.
A migration changes the data model. DOORS Next uses a different type system, a different link model and components instead of standalone modules.
Decisions made at the start, such as which modules to restructure and how to handle baselines, decide whether you end up with a clean platform or with DOORS 9 rebuilt in a browser.
Common concerns, answered on this page
Your data
Most of your DOORS 9 data moves as it is. A few areas work differently in DOORS Next, and we agree them with you in the assessment, before anything moves.
For your own databases, this comes back filled in, module by module, in the assessment report.
Approach
This is the main decision of the project, and you make it per project, not once for the whole database.
Keeps the DOORS 9 structure, so the team recognises every module on day one.
Choose it when
Trade-off: faster to prepare, but the module-by-module structure stays.
Restructures modules into components and reusable types, built for how DOORS Next works.
Choose it when
Gives: components and reuse across products. Global configuration for product lines is available as a separate service. Trade-off: more preparation.
Many projects mix both: active product lines are redesigned, finished projects are replicated or archived.
How it runs
Both platforms run side by side. A module is read-only only during its own migration window. You keep every decision.
DOORS 9
DOORS NextAn inventory of modules, types, links, views, DXL and triggers, and of what is still in use. Then the target design.
A representative set of modules moved to a test server and checked by your users on real data.
Projects move one wave at a time, after cleanup in DOORS 9. Each wave is validated before the next one starts.
Training by role on your own migrated data, and support in the first weeks. Inactive modules stay in a read-only DOORS 9 archive.
Every phase ends with something you can check before the next one starts.
Talk to a consultantWhat you get
Links and attributes move with your requirements, and coverage is measured before and after each wave.
What you have in DOORS 9 and what happens to each module.
Artifact types, attributes, link types and components, replicated or redesigned per project.
Checked by your users on real data before the first wave.
Counts and coverage before and after, for every wave.
For authors, reviewers and administrators, on their own migrated data.
Inactive modules stay available without being migrated.
Services
It depends on the number of modules, the quality of the data and the approach you choose. After the assessment you get a plan with milestones.
DOORS Next stores history differently, so it is handled per project according to the approach agreed in the assessment.
DOORS Next does not run DXL. Calculated values can be migrated, and the logic is replaced with views, widgets or scripts. For many DXL features we have SmarterWidgets 2.0.
Any DOORS 9 version.
ReqIF exchange continues from DOORS Next after the migration.
It depends on the project. We agree it with you in the assessment.
We quote it after the assessment, when the scope is known.
Yes. The target can be your own servers or our managed IBM Engineering hosting.
Leave your details and we will get back to you, usually within one business day.
