FAQ

Where can I find the latest version of Cloud Migrator?

All recent releases of Cloud Migrator can be found in the Cloud Migrator Downloads section of the Litera Customer Center.

1. Go to the Customer Center and log in.
   
   

   Open

   

2. Hover over MY PRODUCTS and click on SOFTWARE.
   
   

   Open

   

3. Once the page loads, scroll down and click on More Info for CAM Cloud Migrator Project License
   
   

4. Click on the version you want to download.
   
   

Where should I install Cloud Migrator?

Because the application itself is fairly lightweight, you should choose the installation server based on its:

• Proximity to the data sources (i.e., SQL server and file share)

• Internet upload speed

Does Cloud Migrator use Windows Presentation Foundation (WPF)?

No, it does not.

What Work data cannot be migrated from an on-premises DMS?

Cloud Migrator currently cannot migrate the following types of data:

• Shortcuts in My Matters/Favorites that point to items outside of the current database

• Document and folder shortcuts outside of My Matters/Favorites

• Search criteria that reference containers outside of the current database

• iManage Share folders

• File handlers (i.e., App Setup)

• Custom forms for classic clients

• Work Web connectors

• Artifacts

How can I improve migration performance?

Migration speed can be affected by a number of factors, including:

• Performance-related settings in Cloud Migrator

• Resource availability on the SQL Server

• Health of indexes and statistics in the staging database

• Network settings/conditions

• File server performance

• Work server performance

To improve general performance:

• Configure a maintenance plan for the staging database that rebuilds all indexes and updates statistics daily

• Increase migration concurrency for the relevant objects

To improve document migration performance:

1. Increase the concurrency for document migration (Tools > Options > Performance > Concurrency > Documents/History)

2. Run Cloud Migrator on a server that is physically close to the file share used by the source Work database

3. Rebuild all indexes and statistics on the CAM.CloudFolder and CAM.CloudDocument tables in the staging database

Can I migrate a Work database that uses the 8.5 schemas?

Yes, when creating a migration via the New Migration Wizard, you can specify 8.5 as the schema version of the source database.

Can I migrate a Work On-Premise 10.x database over?

Yes. When creating a migration via the New Migration Wizard, you specify 9.x  as the schema version of the source database to migrate any 9.x and 10.x version.

Can I put the staging database on the same SQL server as the source database?

Yes, but only if the SQL server is not hosting any databases connected to a production DMS.

Why does Cloud Migrator need DBO access to the source database?

To efficiently handle incremental imports to staging (i.e., deltas), Cloud Migrator keeps track of which rows have been imported to staging by creating a CAM schema in the source database and inserting a record for each imported row in the appropriate CAM.* table. No data in the MHGROUP schema is ever modified by Cloud Migrator.

If I cancel a sync to the cloud, will Cloud Migrator process all items again?

No, every cloud sync only processes items that have:

• Never been processed

• Previously failed

• Been modified in the source since they were created or last modified

How do document number offsets work?

When migrating workspaces or documents, the document number is set based on an item's DOCNUM value in CAM.Folders or CAM.Documents, respectively, plus the Document Number Offset value (Tools > Migration Settings... > Target).

When setting the offset, keep in mind that:

• Once you start a migration, the value should never be decreased.

• Adding the value to an item's DOCNUM should never result in a negative number.

How can I test a migration locally?

In order to perform a migration from one on-premises server to another in a way that mirrors a cloud migration, make sure to take the following steps before starting:

• Configure a Work server with the latest version available from iManage.

• Disconnect any databases from the server that will not be involved in the migration.

Can I migrate users who have spaces in their ID?

No, the Work REST API does not allow spaces in user IDs.

Can I migrate data from a non-Work database?

Yes, you can migrate data from other document management systems by either:

• Converting the source data into a Work database and importing the Work data into staging via Cloud Migrator's Source tab

• Directly populating the staging database with your source data

Can I configure SPM in the cloud during a migration?

No, configuring SPM before completing the migration can prevent Cloud Migrator from being able to migrate all data. If you cannot wait until the end of the migration to set up SPM, you must ensure that the admin account that you are using in Cloud Migrator has not been denied access to any clients, matters, or workspaces before continuing with the migration.

Why are all migrated users enabled in the cloud?

When creating objects in the cloud, all user fields must refer to users who exist and are enabled; if a referenced user is disabled, profile validation will fail and the item will not be created. To avoid this issue during a migration, all users are created in the cloud with their "Allow Logon" property set to true. If a user being migrated already exists in the cloud but is disabled, Cloud Migrator will re-enable it.

At the end of a migration, you can update the "Allow Logon" property of users to match the source via the Update Cloud Users tool (Tools > Update Cloud Users...). To disable users, under Bulk Update, set Enabled to Staging Value and click Apply.

Can I run multiple migrations at the same time if the staging databases are hosted on the same SQL server?

No, running migrations concurrently on the same SQL server is not supported out of the box for the following migration steps:

• Document

• Document History

• Document Security

• Folder Security

• Workspace Security

To be able to safely run multiple migrations on the same SQL server, you must modify the following scripts located in .\Scripts\iManage\Load:

• Documents.sql

• DocumentTemps.sql

• DocumentHistory.sql

• DocumentHistoryIds.sql

• DocumentHistoryTemps.sql

• DocumentSecurity.sql

• DocumentSecurityIds.sql

• DocumentSecurityTemps.sql

• FolderSecurity.sql

• FolderSecurityIds.sql

• FolderSecurityTemps.sql

• WorkspaceSecurity.sql

• WorkspaceSecurityIds.sql

• WorkspaceSecurityTemps.sql

For each instance of Cloud Migrator:

1. Update the names of the global temp tables (i.e., table names prefaced by ##) in each *Temps.sql file to have a unique name (e.g., ##tempCloudFolderA1)

2. Update the references to those temp tables in the other scripts with the same prefix (e.g., DocumentSecurity*).

A feature to dynamically rename global temp tables in static scripts is planned for a future release.

Why does Cloud Migrator need to log in as each user during the user and My Favorites migration steps?

When a user is created in a Work in the Cloud library, the server does not automatically create their My Matters and My Favorites folders. Instead, they are implicitly created when the user logs in for the first time and the Work client gets their contents. To replicate this behavior, Cloud Migrator attempts to log in as each user during the user migration step and requests the contents of their My Matters and My Favorites.

During the My Favorites migration steps, Cloud Migrator must again log in as each user in order to create categories and shortcuts due to Work in the Cloud's lack of an admin API for My Favorites. Support for cloudimanage.com's admin import API will be added in a future release.

How can I migrate My Matters and My Favorites if I used a different tool to create users?

1. If you are migrating to Work in the Cloud, set the migration's default password to the server's impersonation password; for cloudimanage.com migrations, use the Update Cloud Users tool to set the passwords of all users to match the default password.

2. Rerun the user migration step to update the users.

3. Continue with the My Matters/Favorites migration steps.

Why am I getting "Not Found (404)" or "No record found" errors in My Matters and My Favorites migration steps?

For items being created at the root of My Matters/Favorites, a "no record found" error most often indicates that the folder itself is missing, which can occur if Cloud Migrator was unable to log in as the user in the user migration step.

At any other folder level, the error is usually the result of security that was applied after the shortcut had been created, i.e., the user no longer has access to the item.

How can I force an update to previously migrated workspaces, folders, and documents?

• To update a workspace or folder, set its EditedWhen field in CAM.Folders to now (i.e., GETUTCDATE()) and run the workspace, folder, or search folder migration step.

• To update a document, set its Synced field in CAM.Documents to now and run the document migration step.

How do I set limits for uploads?

For builds 23.01.448-484, there was an option only available in the Settings.json file in the user's AppData folder to limit uploads to a specific rate. It was deprecated in build 23.01.488, but it needed to be set to 0 to use the full rate limit allowed by http://cloudimanage.com in build 23.01.484

Processing is running slowly, how can I resolve?

• Try updating the rate limit in the Options menu.

• Confirm iManage doesn’t have a rate limit set from the iManage side.

• Ensure the indexing scripts in the Schema/Staging folder are running.

• Is the iManage database healthy?