Migration Planning and Workflow

Scheduling

At the start of a new migration, the project manager should:

• Speak with all stakeholders and identify critical dates (e.g., start of UAT, final cutover)

• Create a schedule with unambiguous milestones

• Communicate the plan to a member of Litera’s Professional Services Team

Once a feasible schedule has been established, the migration team should agree upon an execution plan, which should detail:

• The customer's requirements

• Any assumptions made by the team

• All tasks that must be completed to hit each milestone

• Ownership of tasks/milestones

• How, and by whom, milestones will be verified

Verifying Source Data

In order to migrate a library to the cloud via the Work REST API, you must first identify and correct any invalid data in the source database.

Common issues that can negatively affect migration include:

• Documents without folder references (i.e. flatspace documents)

• Invalid default values for folder profiles

• Profile references to missing users

• Shortcuts to deleted matters/documents

• Documents that point to nonexistent or zero-byte files

Data Cleanup

Health Check

The health check is a set of database items to check and measure the reliability of the source data and ascertain if there is data that can benefit from a reorganization or cleanup before the migration begins.

• If the source system is iManage, Litera has a free tool for iManage users for the Health Check. Reach out to your Litera Professional Services or Customer Success rep involved in the Cloud Migration project for details to get this.

• Additionally, there are scripts in the Cloud Migrator folder that can be used to do the health check included out of the box.

To view these scripts, go to the following path inside the Cloud Migrator folder: Scripts->iManage->Transform->Select

There are health scripts for:

• Empty Folders

• Flatspace Documents

• Missing Users

• Unused Groups

• Unused Metadata

• Zero Byte Files

Handling Multiple Databases

If your source DMS has multiple libraries, you must decide whether to consolidate them into one cloud library or migrate them individually.

Migrating each database: This method is a less complicated method and doesn't require any additional steps.

Consolidation: This option requires more planning and care. First, check each database for the maximum document number, and set the offset number in the migration options to account for the range plus extra room. If shortcuts are present, these may need to be updated. Lastly, if NRL links are present, which are specific to each iManage DMS, use the NRL Handler tool to remedy. Reach out to your Litera migration contact for this.

Preferred database settings: Ensure only one preferred database is set among all databases migrated. Use the retain preferred database option in Cloud Migrator settings.

Ensure the database name and cloud name remain the same, otherwise, the preferred database and My Matters/My Favorites cannot be migrated properly or work upon migration.

Database Registration: Register the database within the iManage administration, and database management before migrating for each database. Make sure the current database as well as any others migrated are registered. If this doesn't occur, the user could potentially have no access, or the wrong preferred database is set.

Database naming: If the names of the databases differ: Update the docusers table in the staging database to the correct name.

Default Passwords: Since iManage Cloud doesn't have a function for impersonation, the user needs to know the default password before migration.

More importantly, multiple databases need the same default password set for the users, otherwise, the wrong password could be migrated and the user without access. Ensure the preferred database has this default password as well. The Import Cloud Users tool within Cloud Migrator is meant for addressing issues with this after migration, but it could also be used for modifying Staging. The best practice is to update those passwords before the migration begins.

User Acceptance Testing

If it is important to do a trial run of the migration first to a limited sub-set, then a pilot run could be done first before migrating the complete production system. The pilot would usually be done by selecting a set of users, and/or groups and that would limit the content that is migrated. Once the pilot migration occurs, those selected users would smoke-test the cloud system. Any issues or user feedback would be addressed in this trial period before the complete cutover happens.

Workflow

1. 🎯Requirements and Installation Begin prerequisites and installation

2. Creating a New Migration Create a migration

3. Syncing Data to Staging Sync to staging

4. Migrating Objects to the Cloud Push to Cloud