Migration process phases

Preparation

• Assess the value of the overall migration effort.
• Identify potential risk areas that might have an impact on migration.
• Run the Migration Metrics utility to assess the data that you want to migrate:
  • Examine the shape and size of the data; for example, the number of objects, links, OLE objects, and attributes.
  • Consider the hygiene of the data in terms of the consolidated type system. Determine the number of attributes of each type and how similar are they to each other. Remove attributes that have no business value in future work.
• Harmonize type systems to avoid the proliferation of artifact types in IBM Rational DOORS Next Generation.
  • Check for differences in case sensitivity.
  • Check for inconsistent enumeration values in attributes that share a common name.

  For example, consider a scenario in which you have a custom attribute "Importance" in two modules and the attributes were created by using different enumeration types. You might see the following output in your Migration Metrics results:

  

  You can do one of three options:

  • Do nothing and allow Rational DOORS Next Generation to create different attribute types while the package is imported.
  • Rename one or both attributes for a more specific name, such as "Stakeholder Importance".
  • Revise the type in one attribute to match the other, so that the enumeration values are the same in both attributes.
• Convert Layout DXL. Migration of Layout DXL is not supported; however, columns you can convert Layout DXL to Attribute DXL. The calculated values for Attribute DXL are migrated.
• Simplify tables. Rational DOORS supports complex table structures. For best results, simplify the table structure before migrating tables.

Migration

The migration phase can occur over a long time. While it might be advantageous to migrate some project data in the near term, you might need to retain some active project data in Rational DOORS for years. Prioritize your project data and migrate it incrementally when business needs justify the migration. To avoid overloading the content in Rational DOORS Next Generation, do not migrate completed projects. Instead, focus on current and future work that can benefit from the capabilities in Rational DOORS Next Generation.

To migrate modules after you complete your preparation, do these migration tasks:

• Create migration packages in Rational DOORS.
• Export these packages and then import them into Rational DOORS Next Generation.
• After modules are successfully imported into Rational DOORS Next Generation, update the status of the modules in Rational DOORS.

Maintenance

After the migration packages are successfully imported, the original data is maintained in Rational DOORS as a historical archive. Links to the data in Rational DOORS are created when the packages are imported into Rational DOORS Next Generation. Users can use these links access history, baselines, discussions, and other data that was not included in the migration. All new work on the data is done in Rational DOORS Next Generation. Your teams can use both the Rational DOORS client and the Rational DOORS Web Access client to review the historical data. Work in Rational DOORS Next Generation can include these activities:

• More harmonization of artifact types.
• Typical administrative tasks to set up team areas, users, and access controls.

As a one-time occurrence, the migration capability does not update any changes to the data in both tools. After migration, teams can continue to exchange data from Rational DOORS Next Generation and Rational DOORS with customers, suppliers, and other stakeholders by using ReqIF and other formats. However, this data is local in the application where it is exchanged. The data is not updated automatically in the other application that was involved in the migration.