Migrate
Migrate is used to migrate large numbers of workspaces from Relativity Server to RelativityOne. Your data migration will be seamless and intuitive, allowing workspaces to be migrated in just a few clicks.
Related topics:
Permissions
Feature Permissions provide an alternative to Relativity's security management by shifting the focus from Object Types and Tab Visibility to feature-based permissions. This method is simply another option; any feature-specific permissions information already in this and other topics is still applicable. The Feature Permissions interface enables administrators to manage permissions at the feature level, offering a more intuitive experience. By viewing granular permissions associated with each feature, administrators can ensure comprehensive control, ultimately reducing complexity and minimizing errors. For details see
Instance-level permissions and
Workspace-level permissions.
The following minimum security permissions are required to use Migrate.
Tab visibility |
Admin operations |
|
- Access Migrate
- View Admin Repository**
|
- All permissions are set in Instance security.
- The ** indicates permissions needed for non-admin users only.
Migrate considerations
Consider the following when using Migrate:
- Relativity Server instance can only be connected to one RelativityOne instance. That is, you cannot connect multiple RelativityOne instances with a Relativity Server instance.
- Only one migration job can be in progress at the same time, however one migration job can include multiple workspaces.
- Within one migration job, multiple workspaces can be in progress at the same time. Specifically, there may be one archiving, one transferring, and up to five restoring workspace jobs simultaneously during the migration.
- ARM Agents will be shared between Migrate jobs and jobs created through the ARM user interface.
- Migrate uses ARM APIs for archiving workspaces on Relativity Server and restoring workspaces from staging to RelativityOne.
- Migrate “archive and restore jobs” are visible in the ARM user interface.
- Refer to the ARM documentation for any performance considerations.
Take into account also the following:
- Jobs created through either the ARM user interface or using Migrate will use the same BCP path, configured in Instance Settings.
- Migrate uses Transfer API (TAPI) with Data Movement Library (DML) for fast transferring ARM archives to RelativityOne Staging. DML does not require any special configuration, however it is more performant with 8-16 CPU for Relativity Agent(Core) rather than with 4 CPU. See Relativity system requirements (Required configurations for new deployments >> Tier 1 - Hardware requirements >> Relativity Agent(core)).
- You cannot throttle Migrate in the software. The only way to do that is to limit bandwidth directly on agent server on which Migration Data Sender is running.
- If in the Relativity Server instance workspace extracted text is in SQL, Data Grid Text Migration application is run after the migration. For more details, go to Data Grid Text Migration application page.
Migrating Client Domains
Migrate, similar to ARM, is supported for client domains, but migrations can only be performed by a Relativity System Admin. Migrate cannot be used by a client domain administrator due to security restrictions.
Migrating from RelativityOne to RelativityOne
Migrate application does not support workspace migrations between RelativityOne instances. Please use standard ARM and ROSE workflows to move workspaces between RelativityOne instances.