1.Right-click on a category that is not currently part of a case and select Migrate Category to Case.
2.To start a new migration process, select Migrate the category to a case definition and choose the case definition the category should be moved to. If a migration process was previously started, you can also choose to Continue moving documents to the case category using the current settings. This option should be used if a previous migration process was interrupted or failed.
3.Next, decide which category fields will be mapped to the case definition's header fields. This setting determines which category fields will be replaced by the header fields from the case definition you selected. The wizard will try to find the best possible matches, but these should be checked and can, of course, be changed. This mapping will work best if the category and case header are referencing the same Referenced Table. Choosing Keep in category means the field will not be part of the case header, and will remain in the copied category as a category field. All values from the original category will also be retained.
|
These settings are very important as they determine which category fields will be replaced by case header fields. This means local category data will be lost if it differs from the case header data, as the local data is overwritten during the migration process. If these settings are configured incorrectly, the migration of documents will fail.
|
4.When done, click on Next. A confirmation dialog will appear. Click Yes to copy the category to the chosen case definition. Note that is operation is irreversible!
5.Next, the settings for moving the original category's documents must be defined. If new cases should be created for documents whose index data does not match any currently existing cases, select the option Create a new case if no matching case is found. Under Number of documents to move, enter 0 (zero) to move all documents. Alternatively, enter a low number (1-10) to first test the move procedure. The value entered for Move documents in blocks of determines how many documents should be moved in one client/server call. A high value will result in longer delays before the progress is updated, while a low value will result in many calls, which can affect the overall performance of the process. The value entered for Abort move operation after X errors determines how many errors can occur before the move operation will be aborted. Possible reasons for errors are a wrong mapping or a workflow instance still being attached to a document that should be moved. However, tasks and documents links do not cause errors.
6.Select Next to start the process of moving the documents to the category in the case definition. A progress dialog is displayed. Note that this operation is irreversible! Documents that are successfully moved cannot be moved back.
7.A summary page is displayed when the process is complete. The number of errors, if any, is also displayed on this page. Detailed information about errors must be checked in the Thereforeā¢ Server event log.
|