Introduction
Time is passing and the previously implemented and probably extensively used information system sooner or later will require migration to a new platform. A good software platform provides some capabilities for customization for end-users needs and such solutions will require a special treatment when time for migration to a new platform comes.
Migration projects are usually limited by time frames and speed of migration is one of key aspects when D-day comes. When time frames for a migration are defined - they need to be followed, so any potential mistake - which might require a roll-back and repeat of failed steps - must be prevented as much as possible or mitigated. Probably the main factor which might cause a mistake in migration is a human factor. Performing manual operations under time pressure during the migration is a risky factor, so some risk buffers can help to mitigate such risks. But more data is to be migrated - the bigger risk buffer should be added probably. So bigger the migrated system is - more time will be required for the migration schedule. And at some point it is not scalable anymore, and then only a high level of automation can handle such a migration.
Another challenge is that differences in source and target platforms might be quite significant and casual migration tools support only migration of core data, and other significant data is proposed to be recreated on a new platform. So this is again something that needs to be planned and what will postpone the start of using the system after migration.
DOORS Classic to DOORS Next migration
Everything described above is true for lots of cases and so it is for migration from DOORS Classic to DOORS Next. DOORS Next has outstanding functionality, has got significant improvements for handling big amounts of data with version 7.0.2 and more advantages are coming with the latest 7.0.3 release. More and more companies today start planning migration from DOORS Classic to DOORS Next.
Available on the market options will require you to ‘touch’ each migrated module at least once or probably more. Not a big issue for many cases when it is feasible, depending on a solution various additional options which will allow you to start using new DOORS Next features are available. But what if the module counter is too high? How to migrate hundreds or thousands of modules this way?
Another point to think about is creation of Global Configuration structure after migration from DOORS Classic to DOORS Next. In case of getting some feasible for a manual update to Global Configuration structure number of DOORS Next streams it is not a big issue. But what if the number of DOORS Next configurations is counted in hundreds?
Migration Options
Standard migration option, provided out-of-the-box for DOORS Classic to DOORS Next migration is migration via *.migiz package. This tool can be a good fit in following case:
- Cleanup is done in the original (source) system - it means that requirements owners review and prepare the data for migration
- Projects are standalone (or not to much interconnected) - this is related to links between objects
- Migration can be done project by project - taking into account that there are no technical restrictions due to cross-project linking, there are also no other requirements forcing simultaneous migration of projects
Migration via ReqIF - preconditions are similar to migration with *.migiz with some less options (e.g. no mapping to attribute for Artifact Type definition) but there is option for manual update.
Migration via Excel - is more exotic but still possible for some cases (we have done several migrations this way, when the target system was a custom tool).
Migration via 3rd party tools available on the market - we are aware of good migration tools existing on the market. In certain cases we would propose to our clients a solution from another IBM partner, if we see this is better fit for their case.
Migration via Softacus Migrator is the best choice for
- Big amount of data - hundreds of Formal Modules, no resource to ‘touch’ each of them
- Need for migration of “big bang” type - all data needs to be migrated during short time frame
- Interconnected data - objects linked across projects and versions
- Cleanup “on the fly” - automations for cleanup due to huge amount of data (skipping certain Formal Modules - e.g. Change Proposal System and certain attributes)
More about capabilities of Softacus Migrator in the next chapter.
Migrator by Softacus
Softacus Migrator provides several capabilities for migration of big DOORS Classic databases. Migration operator has an option to define rules for distribution of migrated Formal Modules across DOORS Next applications, project areas, components and streams (option for variants migration via update in sub-stream). As migration with Softacus Migrator is highly automated, automated merging of type system is implemented for data types and attribute types Another outstanding feature of Softacus Migrator is an update function, which allows migrating more than one version of Formal Modules, with an option to migrate links from baselined versions. And another related to links migration option is definition of link types for migrated links, or, in other words, creation of custom link types during the migration.
As Softacus Migrator supports migration of huge numbers of Formal Modules, it created a lot of DOORS Next components and streams. So after such migration a lot of components and streams are created and before this data will be ready to use by end-users, Global configurations must be created. And this is also covered by Softacus Migrator with its outstanding feature of Global Configurations Management Project Areas, Components and Streams creation with options to make Global Configuration baselines and build hierarchy (created Global Configurations streams or baselines can be nested to other created Global Configuration streams or baselines).
Another worthy to mention feature is view migration. As DOORS Classic and DOORS Next views have significant differences, migration of views is quite a challenging task. Softacus Migrator can handle views with compatible filters (filters, which can be created with DOORS Next native functionality) and can migrate snapshots of views with incompatible filters (reproduce filtering of artifacts for migrated state). Depending on needs, additional customization can be applied e.g. for DXL Layouts migration (either calculated values can be migrated for the reference or migrated artifacts can be linked to views with DXL Layouts in DOORS Web Access).
1.) Main steps of migration via Softacus Migrator
Described features will be explained in a bit more detail below, here just a short overview of the general approach implemented in Softacus Migrator for migration of big databases. As the migration approach is to avoid ‘touching’ each migrated Formal Module, Migrator can be configured to filter out attributes and views to avoid migration of unnecessary data. Regarding migration of DXL Attributes - Softacus Migrator transfers calculated values, with logging possible exceptions in DXL Attributes executions. So the migration operator has an option to add attributes which fail to calculate or migrate initial values of attributes.
Migration rules
Rules can be scoped to Formal module name, folder names in Formal Module path or value of specific attribute of a Formal Module and they are applied on DOORS Classic project or folder level. This approach can be compared with a fishnet, which captures specific items on an industrial scale. Rules are also defining migrated versions of Formal Modules - for example we can specify with rules the latest baseline and current version to be migrated. An alternative for fishnet is fishing rod, which in our case is a GUI tool for manual distribution of modules.
Type system merging automation
For migration of enterprise scale DOORS databases our migrator provides type system merging automation. In DOORS Classic type system (data types, attribute types) is defined on a module level. And in DOORS Next type system is managed on component level (to keep it simple we won’t mention streams here). So when two modules are migrated to a component, type systems of those modules are merged when items are compatible (merging is performed based on names and data types). If some attributes are unwanted for migration - they are skipped on the initial phase, downloading from DOORS Classic.
Update functionality
Our migrator provides a unique option to update mitigated modules, which is used for migration of multiple versions of a formal module. Update can be performed within a same stream, e.g. migration of specified baselines of a Formal Module. Another option is to make an update in a child stream, which can be used for migration of variants (depending on an approach of managing variants in the source). All these operations are fully automated and streams are created within a single run on migration. Depending on requirements, migration of baselines can also include links. Migrated to DOORS Next versions will be baselined on the new platform.
Link types
Migrated links can be created with default type (Link To/Link From) if no additional input is provided. Or the input file for migration can be extended with link types definition based on various parameters. For example, we can specify link types based on component names of source and destination artifacts - e.g. we specify link type between artifacts in components ‘System Requirements’ and ‘Customer Requirements’, and so on. Besides component names we can stick to module names, DOORS Next servers (as migration to multiple DOORS Next servers is also supported) and module paths in the source - DOORS Classic database.
Global Configuration Setup
If the migrated database (or databases, as we support migration from multiple DOORS Classic databases in one shot) is big enough, a significant amount of DOORS Next components could be expected to be created. And if migration includes versions of modules which have certain linking dependencies - in DOORS Next this should be resolved with proper Global Configuration structure. And this is possible with our migrator. An input file for migration can be extended with Global Configuration section, describing expected after migration structure in the GC application, and it will be created with one click.
2.) Example of EasyStart sample project migration
Summary
Summing up, Softacus migrator supports migration of huge databases with less effort and outstanding performance, but at the same time can support complicated scenarios even on smaller scale data. Our experienced team can support additional cases specific for your data, and provided by Softacus extensions will make moving to the new platform easier.
Softacus Services
We, in Softacus, are experts when it comes to consulting and service delivery of IBM software products and solutions in your business. We help our clients to improve visibility and transparency when licensing and managing commercial software, providing measurable value while increasing efficiency and accountability and we are providing services in different areas (see Softacus Services).
IBM ELM extensions developed by Softacus are free of charge for the customers who ordered IBM ELM licenses via Softacus or for the customers who ordered any of our services. If you are interested in any of our IBM ELM extensions, you found a bug or you have any enhancement request, please let us know at info@softacus.com.
Related and Referenced Topics
Blog Articles:
Basics of Links and Link Types in IBM DOORS Next Generation - learn the basics about the linking and link types in IBM DOORS Next.
Linking Techniques in IBM DOORS Next - article explaining basic concepts and showing multiple ways of creation of links between artifacts.
Link By Attribute Feature in IBM DOORS Next - the article explains how to use the "Link by attribute" function to automatically create, update, or delete one or more links between artifacts based on values in the attributes of the artifact.
Softacus Widgets:
Link Switcher - widget developed by Softacus, that converts the context of artifacts links in a very short time.
Module Link Statistics - extension that provides users with a quick overview of the amount of the links in specific link types in a module.
Link Type Change- extension developed by Softacus designed to enhance the functionality of DOORS Next Generation by allowing users to manipulate the direction of a link or convert it to another type of link.
Links Builder- extension that allows the users to create a link between two artifacts in DOORS Next Generation according to the certain rules.
Link by Foreign Attribute - this extension allows users to create links between artifacts in the selected module(s), based on the attributes values.
Show Attributes of Linked Artifacts - this extension shows the attributes and links of the artifact that is currently selected.
