Migration

You can copy, or "migrate," base documents from one case to another. When a document is migrated, the original document remains in the source location. The migration process creates a copy of the document in the destination location. 

Note: The source case and the destination case must be in the same portal, and the administrator must have the appropriate permissions for both cases. 

Information about migrating fields and objects 

The following information relates to the migration of fields and objects. 

Fields and objects available for migration 

The following fields are mandatory and are always migrated: 

Note: You can choose to migrate or not migrate any system fields that are not included in the following list. 

Document ID: The application maintains the Document ID throughout the migration process. If a document is migrated but its Document ID already exists in the destination case, the application updates the document in the destination case based on the setting selected for updating existing documents. 

Note: After a document is migrated, if the Document ID is changed in either the source case or the destination case so that they no longer match, and then the document is migrated again to a new destination case, the application creates a new document in the new destination case. 

Levels: All documents are assigned the same levels in the destination case that exist in the source case. 

Source/attachment relationships: If a user migrates partial families, only direct source/attachment relationships are maintained. For example, Document C is attached to Document B, and Document B is attached to Document A. If the user migrates only Document A and Document C, the documents do not have a source/attachment relationship in the destination case. 

Portal Document Globally Universal ID (GUID): Use this value to track documents that have been migrated between cases. If a document in the source case does not have a value for Portal Document GUID, the application assigns a value for Portal Document GUID before the document is migrated. 

Note: You cannot edit this field. 

Pages: When migrating documents that do not already exist in the destination case, the application migrates all page records, including those that are visible in the Image Viewer on the Documents page. When migrating documents that already exist in the destination case: 

If the user selects the option to update pages in the Migration window, the application updates the page records in the destination case to match the source case. 

If the user does not select the option to update pages in the Migration window, page records in the destination case do not change. 

Files: When migrating documents that do not already exist in the destination case, the application migrates all files associated with the source document. When migrating documents that already exist in the destination case: 

If the user selects the option to update files in the Migration window, the application migrates all files associated with the document in the source case and overwrites any files already in the destination case. 

If the user does not select the option to update files in the Migration window, the application does not copy any files. 

The application does not delete files from the destination case, even if they no longer exist in the source case. 

The following fields and objects are migrated based on the user's selections: 

User-created fields: These include all fields found in Case Setup > Fields. 

Document fields: These include Document Date, Document Type, Document Title, Document Description, and Estimated Date. 

Annotations: Users can select specific annotation types to migrate. 

Notes: Users can select specific note categories to migrate. 

Binders: When creating migration column templates in preparation for migrating documents, users can migrate either all binders or no binders. Users cannot currently select specific binders to migrate. This is configured when creating your migration column template. For more information, see Create migration templates. 

Issues: When creating migration column templates in preparation for migrating documents, users can migrate either all issues or no issues. Users cannot currently select specific issues to migrate. For more information, see Create migration templates.  

People and Organizations: Users can select specific correspondence types to migrate, including custom correspondence types. Only values directly assigned to a document are migrated. Values that are associated with a document only through a link are not included. For example, Person A is coded to a document; Person A is linked to Organization A; Organization A is not coded to the document. Only Person A is migrated for the document. If a document is coded to a Person and an Organization, and the two are linked to each other, both values are migrated and linked in the destination case. 

Fields and objects not available for migration 

The following are examples of the types of data that are not available for migration: 

System fields that contain information specific to a case, such as: 

Fields that contain a job ID, such as Import ID or Evidence Job ID. 

Fields that contain status messages, such as Document OCR Status. 

Fields that indicate when and how a document was added to a case, such as Document Created Type and Date Added to Case. 

Fields that display information derived from other fields or data, for example, Page Count. 

Entities (Data Models). Entities that are normally created when importing data, such as People, Organizations, and Custodians, are created in the destination case and are not copied from the source case. 

Productions (including renditions, which are not available to migrate at this time). 

Predictive coding data 

Search term families 

Audit history data 

Private binders 

Transcripts 

Suppressed documents 

Fields and objects that do not exist in the destination case 

The following applies when you migrate objects that exist in the source case but do not exist in the destination case: 

In general, if an object such as a field, binder, issue, annotation type, note category, correspondence type, or level is migrated with a document, but the object does not exist in the destination case, the application creates the object in the destination case. 

Note: The migration process does not assign group permissions to new objects.  

The application creates "Family rank" pick list fields as regular pick list fields. A user can change the field properties in the destination case. 

The application creates security override binders as regular shared binders and not security override binders. 

The application does not migrate descriptions for binders and issues. 

The application does not migrate level labels. 

In most cases, the migration feature does not retain data associated with users and dates. For example, migrated field values reflect the user performing the migration and the date the data was migrated. However, the following exceptions apply: 

Annotations retain the user and date information from the source case. If the user does not exist in the destination case, the values reflect the user performing the migration. 

Notes retain the user and date information from the source case. If the user does not exist in the destination case, the values reflect the user performing the migration. 

Prepare to migrate documents 

Before migrating documents, administrators must enable the Migrations feature and should create a column template to define the specific fields and objects to be migrated. 

Enable the Migrations feature 

To enable the Migrations feature, administrators must grant users access to the Processing - Migration feature. 

To grant or deny access to this feature: 

On the Case Home page, under Security, click Features. 

In the row for Processing - Migration, under a group column, click the Allow or Deny option. 

Create migration templates

Note: You must be a Case Administrator to create a migration template. 

To create a migration template: 

On the Case Setup > Column Templates page, click Add to open the Add column template window. 

On the Properties page, enter a name for the template. Templates are listed by name when you create a migration job. 

In the Type list, select Migration. 

Click Next. 

On the Fields page, use the checkboxes to select fields and other objects to migrate. Click the checkbox at the top of the page to select all fields and objects. Click the checkbox for a grouping to select everything in the group. Use the search box to find specific fields. 

Click Next. 

The Annotations page displays all redaction and highlight types in the case. Use the checkboxes to select the redactions and highlights to migrate. 

Click Next. 

On the Security page, select which groups can use the template. 

Click Save to create the template. 

The new template appears on the Case Setup > Column Templates page. 

Migrate documents 

To migrate documents: 

On the Documents page, in the List pane, select the check box next to the documents that you want to migrate. 

Note: The greater the number of documents migrated, the longer the migration process takes. Best practices dictate migrating no more than 500,000 documents at a time. 

On the Tools menu, under Output, select Migration. 

The Migration window appears. 

At the top of the Properties page is a message indicating how many documents you have chosen to migrate. Select the checkboxes next to the options to set the properties related to these documents: 

Include missing source or attachment documents 

Description 

Update group coding fields 

Run indexing and enrichment after migration 

Click Next. 

On the Destination page, select the destination for the migrated documents. 

Note: The original document remains in the source location. The migration process creates a copy in the destination location. 

Click Next. 

On the Existing Documents page, use the following options to determine if the documents you have chosen to migrate already exist in the destination location and what should occur if they do. 

Check destination case for existing documents: Click Run check to determine whether the documents you have chosen already exist in the destination location. 

Action:  

Select Abort migration, if it contains an existing document ID to cancel the migration job if any of the documents you selected for migration shares the same document ID as a document in the destination location. 

Select Migrate new documents and update existing documents in the destination case if you want the migration to continue. 

Select Append or Update to determine how the migration process handles field values. Selecting Append adds the new value to the end of the existing value. Selecting Update updates the value with the contents of the migrated field. 

If you choose to update the fields, select any of the following elements to update: 

Source and attachment relationships 

Pages 

Files 

Note: The migration process overwrites existing files. For more information on appending and updating, see Append vs. Update existing documents. 

Click Next. 

On the Fields page, select your migration template or choose to migrate all fields. 

Note: The greater the number of fields and objects migrated, the longer the migration process takes.  

Note: If you select All Fields in the migration window instead of a custom template, all fields that are available to add to a migration template are included, except Annotations and [RT] Family MD5 Hash. [RT] Family MD5 Hash is recalculated based on the [RT] MD5 Hash values that are migrated. If you want to include the family hash instead of recalculating it, use a custom migration template. 

Click OK. 

Append vs. Update existing documents 

The following general rules govern the differences between updating and appending existing documents in the destination location: 

One-to-many fields: Append only adds values and never deletes values from the existing document in the destination case. 

One-to-one fields: Append updates a field to a different value if there is one in the source case. Append does not update a field to have no value, even if it has no value in the source case. 

People and Organizations: Same behavior as one-to-many fields. 

Group coding fields (All Custodians, All File Paths, and All Evidence IDs): These always act like an Append action even if you select Update. 

Binders: The migration process adds existing documents to any additional binders but never removes documents from binders. 

Issues: The migration process adds existing documents to any additional issues but never removes documents from issues. 

Annotations: New annotations are added but annotations are never removed as part of the migration process. If an annotation already exists with the same type, name, and location, a duplicate annotation is not added. 

Notes: New notes are added but notes are never removed as part of the migration process. If a note already exists with the same category, date, text, and private designation, it is not added again. New replies to the note are added. If a note that is also an annotation already exists with the same category, date, text, private designation, page number, and location, it is not added again. 

View Migration job properties 

Administrators can view the properties and progress of migration jobs on the Migration page.  

To view information about Migration jobs, on the Case Home page, under Manage Documents, click Migrations.