Migrate Workspaces

This page details the specific configuration and input options for the Migrate Workspaces Orchestrator

This guidance should be read in conjunction with the Common Configuration page which details the standard application configuration.

Operation Name

Migrate

Common Configuration

There is common configuration available within this job Orchestrator. The common configuration options can be found here.

Purpose

The key purpose for this Orchestrator is to target and migrate directory structures, including metadata, from a target to a destination. The primary use case of this orchestrator is for archiving purposes.

Think of it as a batch copy/cut-and-paste tool that:

• Takes a list of locations to migrate (like root folders)

• Copies everything inside them (subfolders and files) to a new location

• Deletes the originals after successful copying

• Tracks what was moved, what succeeded, and what failed

• Records all activity for auditing purposes

Target and Destination are configurable with the following configurations currently supported:

• iManage → Azure Blob Storage

• Azure Blob Storage → iManage

• iManage → Local Filesystem

• Local Filesystem → iManage

• Azure Blob Storage → Local File System

• Local Filesystem → Azure Blob Storage

Metadata for each root, folders and files are stored alongside in a JSON file with the .tec.json file extension. This shouldn’t be edited, and is used to persist the metadata for each entity after it’s migrated. This file will only be created if the integration doesn’t have a built in metadata mechanism, such as Local and Azure Blob Storage.

Known Limitations

• Importing into iManage will create a new Workspace each time. This means that if an import happens multiple times (i.e. a failure occurred in a previous run), a new workspace will be created each run.

  • It is recommended that if this is a concern, to configure Administrate not to delete the target on migrate, review the migration and then manually delete the target if happy.

  • The reason for this limitation is due to Administrate not being aware of previous migrations, and so is unable to determine whether a particular workspace has been imported previously.

• This orchestrator cannot be used to transfer between iManage libraries. Use the Move orchestrator to facilitate this.

Input Data Schema

Data can be read via SQL or CSV and requires the following data headers and values:

CSV

SQL

SQL Input uses the same values as the CSV input above. The SQL Schema is detailed below:

CREATE TABLE MigrateInput (
    Id INT IDENTITY(1,1) PRIMARY KEY,
    Processed BIT NOT NULL,
    TargetIdentifier NVARCHAR(MAX) NULL,
    TargetObjectSearchContainer NVARCHAR(MAX) NULL,
    TargetObjectSearchQuery NVARCHAR(MAX) NULL,
    DestinationIdentifier NVARCHAR(MAX) NOT NULL
);

Job File Options

This section details the configurable options within the orchestrator.

Integrations

Each provider requires its own specific data to connect to the service.

If you are using multiple providers, you will need to ensure both are added and valid (Administrate will warn if data is missing).

iManage

This follows the same pattern as other orchestrators with iManage integrations.

The simplest configuration requires:

• URL - The URL for iManage.

• Username - The username for the account to log in as.

• Password - The password for the account to log in as.

"IManage": {
    "URL": "<https://cloudimanage.com/>",
    "Username": "{Username}",
    "Password": "{Password}"
}

Azure Blob Storage

Azure Blob Storage allows access to the service with two pieces of information that can be generated in Azure:

• AccountName - The account name in Azure.

• Key - The key provided by Azure (these are generated in Azure and can be changed at any time for security purposes).

With these two pieces of information, the service is granted access to the storage account.

"AzureBlob": {
    "AccountName": "{AccountName}",
    "Key": "{AccountKey}"
}

Local

The local integration does not require any configuration. However, due to the pre-checks currently in Administrate, an empty stub is required.

ℹ️ Note
This will be removed in a future release.

To satisfy the pre-checks, you can add this:

"Local": {
    "stub": ""
}

Sample Job File

This is an example Job File for the Migrate Orchestrator. This includes all options for each integrations, however as mentioned above, if a specific integration is not being used, it does not need to be included in the configuration.

{
  "Operation": "Migrate",
  "Options": {
    "Enabled": true,
    "ActionMultipleQueryResults": false,
    "Target": "IManage",
    "Destination": "AzureBlob",
    "DeleteTargetAfterMigrated": false,
    "MigrateFromCSV": false
  },
  "InputType": "SQL",
  "Inputs": {
    "CSV": {
      "Path": "PATH_TO_CSV"
    },
    "SQL": {
      "ConnectionString": "",
      "Table": "MigrateInput",
      "Schema": "dbo"
    }
  },
  "Outputs": {
    "Console": {
      "Enabled": true,
      "SubscribedTo": ["Application:*:*"]
    },
    "CSV": {
      "Handlers": [
        {
          "Enabled": true,
          "Path": "PATH_TO_CSV",
          "FileNameTemplate": "Administrate_Report_<DATETIME>",
          "SubscribedTo": [ "*:*:*" ]
        }
      ]
    },
    "SQL": {
      "Handlers": [
        {
          "Enabled": true,
          "ConnectionString": "",
          "Table": "MigrateOutput",
          "Schema": "dbo",
          "SubscribedTo": [ "*" ]
        }
      ]
    }
  },
  "Integrations": {
    "IManage": {
      "URL": "https://cloudimanage.com",
      "Username": "",
      "Password": ""
    },
    "Local": {
      "stub": ""
    },
    "AzureBlob": {
      "AccountName":"",
      "Key":""
    }
  }
}

Output Events

The following output events can be persisted via the ‘Subscribed To’ configuration

These should be listed in the Orchestrator in the following format ‘Target:Action:Status’.

The event output schema is shown below:

CREATE TABLE MigrateOutput(
	Id INT IDENTITY(1,1) PRIMARY KEY,
	CorrelationId VARCHAR(36) NOT NULL,
	EventTime DATETIMEOFFSET NOT NULL,
	Action VARCHAR(MAX) NULL,
	Status VARCHAR(MAX) NULL,
	Message VARCHAR(MAX) NULL,
	DataSourceRowId VARCHAR(25),
	TargetObjectType VARCHAR(25) NOT NULL,
	TargetSearchQuery nvarchar(max) NULL,
	TargetSearchQueryResultCount int NULL,
	TargetSearchQueryResultList nvarchar(max) NULL,
	TargetObjectIdentifier VARCHAR(max),
	DestinationObjectIdentifier VARCHAR(max) NULL,
	EntityTargetId VARCHAR(MAX) NULL,
	EntityDestinationId VARCHAR(MAX) NULL,
	EntityAction VARCHAR(MAX) NULL,
	EntityStatus VARCHAR(MAX) NULL,
	EntityDetails VARCHAR(MAX) NULL
)

Failure and Skip Behaviour

This Orchestrator follows the standard behaviour for failed/skipped records:

Skipped = Scenarios configured to not be processed for a specific reason

Failed = Administrate tried to perform an action on the target or destination integration and an unexpected error occurred. e.g. iManage connection dropped and Administrate was unable to move a folder within the workspace.

iManage Behaviour

This section details the different behaviour across different versions of iManage i.e. On-Prem, iManage Cloud and Cloud iManage, as well as known limitations for the orchestrator.

Limitations:

• Subclasses associated with workspaces which are not present in the destination library will need to be added manually before the workspace can be successfully moved.

• Enterprise users in the source library not present in the destination library will need to be manually added before the move operation can complete successfully.

Skip events:

Troubleshooting