Checklists

Note any unsupported items that will not be migrated.

View here the current list of unsupported items

iManage Work Server updated to 10.3.0.286 or higher in the cloud

DMS impersonation password might be necessary.

Migrated users' passwords are set to the default password set when creating a new migration. This password is used for actions like Creation of My Matters (Worklist) and My Favorites (Worklist) folders for a user. If the users don't have this password, either change it to the same password, or use the impersonation password.

Increase the thread handling for the migration.

Increase the threads for the staging to cloud migration. Leave the threads as-is for the duration of the migration.

Communicate the go live date to all stakeholders of the migration.

Download/Upload speeds on the network

The upload speed is important when Cloud Migrator is uploading documents to the cloud. Speeds lower than 50 Mbps may result in longer time to upload documents.

SQL or Windows account with DBO rights to the source and staging database.

Health check was run, and data clean-up was performed.

The health check determines if the existing dataset has data that can be cleaned up or reorganized. Data that can be flagged would be: Empty folders, orphaned documents, unused metadata, null data or flatspace documents. See the Best Practices section for more information on this health check.

If flatspace documents exist, the firm doing the migration needs to exclude the workspace that the flatspace documents are put into, from the refiling service.

Documents could then have a incorrect modified document profile from the refile service.

Stop flat space filing in the source before beginning the exercise.

Disable Security Policy Manager (SPM) before migrating.

Any restricted client or matter in SPM will not migrate using Cloud Migrator. Access Denied errors will result if these are migrated.

Turn off the OCR service in the cloud.

OCR creates newer versions of the documents and collides with the migration processes. Validation can also be affected with OCR on.

Additionally, enable any disabled users before beginning migration.

If user is disabled on source, then they will be missing from the ACL. Currently the client needs to manually enable them, run the migration, and then disable then again.

Do not disable the users midway in the migration.

Decrypt the servers before migrating if servers are HIPAA enabled, or encrypted.

The iManage API doesn't support uploading encrypted content to the cloud. Cloud migrations would fail if synching from an encrypted iManage source.

Check if using Customer managed encryption keys (CME).

If encrypted in the Cloud target system, no issues. Migrator's API will connect with the target.

If encrypted in the source, Cloud Migrator will not work, and would need to be decrypted.

If using linked folders through exchange, ensure Work Communication Server for Exchange (WCS/WCSE) is turned off in iManage cloud as this may result in emails that are filed to be deleted.

o If WCS needs to be on, communicate to the project stakeholders, and consider these consequences and their effect.

o If WCS needs to be on, have iManage set DOCNUM to a higher value than migrated document numbers, so there is no interference in migration.

o The Cloud Migrator will confirm if WCS/WCSE is turned off before the sync to cloud occurs.

If consolidating multiple databases, check for the maximum document numbers and set offset accordingly. Additionally ensure preferred database is set to one database, and that all users have the default password the same on all databases.

See best practices.

Contact iManage to have the docnumbdb value updated to a higher value than the source max docnum.

Ensure to use one staging database per source database.

Prepare indexer for import.

Turn it to Initial Mode, as the indexing should not be running while a migration occurs.

Multiple source databases do not have multiple workspaces with the same custom1/custom2 values in each of the multiple databases, as this can throw off the sync.

How are the users spread among the databases?

• If users are all in a single database, that is ideal. Sync off that database.

• If users are spread in multiple databases, run the users part of the sync for each source database. Only new or missed users in each sync would be processed.

Create the SQL staging database on the network where the on-premise source database is.

The user running the Cloud Migrator needs at least READ rights to the iManage file share.

Tip: test via RUN if the iManage file share is accessible from the Cloud Migrator machine.

Review the options within Cloud Migrator and adjust if necessary.

• Timeouts

• Concurrent Cloud Object Creation

Create a weekly maintenance plan for the staging database(s).

Include the following on the weekly schedule:

• Check database integrity

• Re-organize indexes

• Rebuild indexes

• Update statistics

If maintenance on the database doesn't occur, syncs from source might fail. Sync performance may be impacted.

Ensure all Pre-Migration checklist items are completed.

Don't run any service in the cloud (for example refiling in the cloud), that modifies the target library until the migration is completed fully.

Sync the data from source iManage to Staging. Document history is optional if it’s too large (>20 million rows) and can be separately run after the initial sync completes. Check the logs for errors in the job.

Sync from Staging to Cloud. The sync should be done in stages:

Sync first: Users and Metadata. Wait for completion. Validate.

Sync second: Workspaces, Folders and Documents. Wait for completion. Validate.

Sync third: Document History, My Matters and My Favorites (Worklists). Wait for completion. Validate.

If steps 1-3 were done in Pilot, continue on with the full production migration.