For various reasons a migration can be stopped/cancelled/aborted/failed. To support this the migration behavior attempts to be robust to restart scenarios. The input to a restart of a migration is the XMI file. This contains the scope of the migration as well as what has been completed in the migration.
Under all restart situations, the application attempts to discover what has been completed in the DOORS Next environment. Once it has identified what has been successfully completed, it restarts at a stable point of definition (components and changesets). Any partial migrations will be ignored.
Restarts fall into two categories:
At the conclusion of each DOORS Next Component migrated the application saves a “Recovery_*.xmi” file in the temp directory of the migration. The last written one of the migration captures the most complete part of the migration. Use this as the input to the migration for the scope (instead of the excel configuration file). The application will restart and continue.
This scenario is most typical of a DOORS Client or Client machine failure or login timeout.
Sometimes when doing a migration there are 10 of the 12 modules that are approved in the migration, but something is incorrect with two of the migrations. In these cases simply discard the two changesets, make the appropriate changes (in the mapping file or DOORS content) and restart the migration. The tool will then only update the two modules with deleted changsets.
This scenario is most typical of a missed attribute mapping or DOORS data update that was missed.