Overview

This document will detail the steps that are required when migrating a Curator System database and configuration from one system to the next.
Note: This guide was written with the Curator Arrival 3.5 Release.

Typical use cases are below:

• Creation of a new Production System, on new server hosts, when the old data and configuration are still required to be present on the new system.
• Migration of configuration from a Production or Development System to a new Development or Production System. For example, a Production System has been fully deployed and configured and now the Development System is being deployed. To avoid manually having to re-do all the permissions, metadata structure etc., migration of database and configuration following these steps can save time.

This document assumes that the new Curator System has already been installed, the configuration is default/OOTB and the curatordb contains no/minimal assets which are fine to be removed/purged. 

Step 1 – Schema/Database backup & restore

The first step is to backup the schemas from the existing system at the point where you are happy with the configuration and content of the existing system. The backups can be carried out in MySQL Workbench on the existing system and you should look to backup the following schemas:

• curatordb
• processengine
• devicedirector
• xchangemanager (if applicable)

Once the backups are complete, each of these backed up schemas can be restored in place of the existing schemas of the same name on the new system (drop the existing schemas first). Note that all Windows servers affected should be stopped when carrying out these restores. Do not start the Windows Services once the restores are complete.

Step 2 – Purging data from restored schemas

The next step we need to carry out is the purge of data from the restored schemas. This is done so that the new system does not affect any assets/files that are controlled by the existing system. Carry out the following queries in MySQL Workbench for each schema:

• curatordb:
  1. DELETE FROM curatordb.media;
  2. DELETE FROM curatordb.audio;
  3. DELETE FROM curatordb.images;
  4. DELETE FROM curatordb.folders WHERE folder_type = 4;

• processengine:
  1. DELETE FROM processengine.process;

• devicedirector:
  1. DELETE FROM devicedirector.job;

• xchangemanager:
  1. DELETE FROM xchangemanager.media;

Step 3 – Gateway Setup

Now you have your restored schemas cleaned up, you can restore access to the new system. You’ll need to browse to the CuratorGateway URL of the new system and you’ll find that you have to step through the initial setup steps once more, such as setting the MySQL host and password up.

Note that this configuration lives in the curatordb, so the schema restore will have brought that configuration from the existing system, so this needs to be overwritten at this step.

Once that’s done, be sure to update the following pages with the correct details applicable to your new system:

• Clients (Root URI specifically)

• External Providers (usually should stay the same between systems)

• Email Provider (usually should stay the same between systems)

• API Routes (Host specifically)

This should now allow us to access the client and admin WebApps and we’re going to step through these one by one, don’t start those Windows Services just yet.

Step 4 – XChange Manager Setup (if applicable)

If your system has XChange Manager installed and in use, it’s time to update the devices and volumes where appropriate. It’s easiest to do this directly in the database, and that way your volumes can keep all of their settings from the old system. In MySQL Workbench run the following query:

• devices;
  1. SELECT * FROM xchangemanager.devices;

This query will return all storage devices and their paths. If on your new system you are using the same storage devices, nothing needs to change here. If they are different, you can update the path in MySQL Workbench here and apply the change.

• Volumes
  1. SELECT * FROM xchangemanager.volumes;

This query will return all volumes and their paths. These will almost certainly need to be updated, otherwise you will be detecting the same files on both your existing system and new system (unless this is a migration, in which case you might want to do that anyway). Update the paths in MySQL Workbench and apply the changes.

Once the above is done, you can start the IPV XChange Manager service. Browsing then to the XChange Manager website, you should see your changes applied in the GUI.

Step 5 – Device Director Setup

Moving onto Device Director, you can start the IPV Device Director service. Now browse to the Device Director website and update the following tabs:

• Devices
  1. Update Hosts, or remove Devices to avoid crossover with existing system.

• Profiles
  1. Updating any paths to files for example EPR profiles, to avoid crossover with the existing system

• Groups
  1. In theory, groups should remain intact, if Devices are not removed, only updated.

Step 6 – Process Engine Setup

The final and trickiest step is the Process Engine setup. Note that the most damage can be done with this service, as once started, the system will automatically kick off jobs as part of its autostart functionality. So you’ll need to move quickly through the first few steps here to avoid crossover with the existing system.

Now, once ready, start the IPV Process Engine service, then the steps are:

• MediaStore – SYSTEM-MONITOR
  1. Remove all values from key “PersistentWorkflows” (make a note of these, you might want them later).

• MediaStore – XCHANGEMANAGER-… (all XChangeManager MediaStores)
  1. Change value to False where key is “AutoStart”

• Home tab – Configure Hosts
  1. Update Hosts to be those of your new system

• Home tab – Basic Configuration
  1. Update configuration to be that of your new system, environment, full path to Curator folder etc.

• Home tab – Configure Email Settings
  1. Likely doesn’t need updating, but update to differentiate from existing system.

Now the key items are updated, you can continue the configuration to update the following:

• MediaStores
  1. Update paths on all custom stores so there is no crossover with existing system.

• MediaStores – XCHANGEMANAGER-…
  1. Change value to True where key is “AutoStart” (now the path has been updated, these MediaStores will no longer crossover with the existing system).

• MediaStore – SYSTEM-MONITOR
  1. Add back in recorded value for key “PersistentWorkflows” (now all paths have been updated, there should be no more crossover with the existing system).

Conclusion

This concludes the steps required to migrate the schemas and configuration from one Curator System to another. At this point, extensive testing should be carried out to confirm all functionality is intact and working. There is always a chance that human error may play a part in a migration like this, or there are environmental issues which cause issues, this is why extensive testing is recommended.