Migrate an Omniscope server installation from one machine to another

This article provides information on how to move the Omniscope server installation from one machine to another.  

The document uses several terms like <user home> / App data - terms for which you may need a system administrator to help you to find or give you permission to access (see the end of this article for more information as to where to find them).

Warning: We strongly recommend that you set up your new Server machine first, and make sure everything is working as expected before you delete Omniscope from the existing machine. Visokio is happy to provide a temporary key to help with migration, contact support[at]visokio.com for more information.

NOTE: This document is primarily aimed at Omniscope Evo installations but also applies to Omnsicope Classic.

Before proceeding, you should take a full backup of the server (if it's a VM, we recommend a full disk snapshot), in case you accidentally change something on the original server.

Step 1: Install Omniscope on new server

Install Omniscope onto the new machine and make sure the license is activated. Visokio would be happy to provide a temporary key for the transition. Ensure Omniscope is not still running, before continuing.

Step 2: Copying files to the new location

This step involves copying all the required files from your current installed machine to the new machine. For typical locations of <USER_HOME> etc., see further down.

List of files/configurations you need to migrate:

1. <USER_HOME>/omniscope-server folder, in the user home directory, e.g. /home/ubuntu/omniscope-server. This contains your files folder with all projects. (On very old installations, you might see mobile instead of files, a setting in config.xml influences this. You should adopt the files naming on the new server, ideally.). This folder also contains the config.xml with app settings and top level permissions.
   
   Copy the entire folder across, exactly, except for the omniscope-server/logs folder (it's best for the new server to have a clean slate in terms of logging).
   
   NOTE: You may need to adjust the paths in the config.xml and folder.xml, if necessary, by editing them manually using a text editor.

2. <INSTALLATION_LOCATION>/installconfig.properties (Windows) or

           <INSTALLATION_LOCATION>/_launch.sh (Linux) 

If you have not customised this, or if porting between platforms, skip this step.

3. This step only applies to Omniscope Evo installations
   
   <APP_DATA_VISOKIO>/Omniscope/LocalStorageRegistry.xml 
   (If you are using Storage Blocks, which store data outside of projects, this is essential to migrate their data. If you aren't, you will still need to copy the file if you are migrating MonetDb.)
   
   <APP_DATA_VISOKIO>/Omniscope/diskManagerSettings.xml
   (Although you may prefer to configure the new server independently via Admin > Disk Manager, particularly if the new server has a different filesystem arrangement)
   
   <APP_DATA_VISOKIO>/Omniscope/MonetDb/
   (Again, this is essential if using Storage Blocks. Otherwise it is optional, and if omitted, reports will rebuild their data from execution data on next open, incurring a short delay. Note, the location may be customised on either old or new server, in Admin > Disk Manager)

For the purpose of clarification, there are some items you typically should not migrate:

• <USER_HOME>/omniscope-server/logs (as per comments above)
• <USER_HOME>/Visokio Error Reports (for the same reason)
• omniscope-dm-temp, the "Workflow App temp" folder, typically in a temp directory, unless customised (this should only contain temporary data used during workflow execution and should be empty otherwise, with nothing needing migrating)

Step 3: update configuration

If the new server has identical installation, user account, sharing folder (etc.) folder paths, you have nothing to do here. Otherwise you should edit the server configuration to correct any paths. 

For example, if running a production web server with HTTPS certificate, you may need to transfer and update the path of the keystore.jks file. Typically this can be done either by editing config.xml manually or in the Admin UI after starting the server.

For example, if you have a project with an (e.g.) File or Database block accessing some external resource, you may need to reconfigure the project with the correct path or host name (as appropriate) to reach the same resource.

Step 4: New Server testing

This step involves testing to make sure everything is working on the new server, before the changeover. Some of the tasks you should check: 

1. Check the paths in the installconfig.properties/_launch.sh, config.xml, LocalStorageRegistry.xml (Evo only), diskManagerSettings.xml (Evo only) are all valid.

           
            You will need to reconfigure your JDBC drivers again on the new machine through Admin Web App and

            re-apply any Advanced settings you may have set manually outside of Omniscope.

2. Check Admin Web App by checking logs, after you've started the application.
   
   

3. Test opening files and folders with configured Omniscope Server permissions to make sure they are accessible

We advise doing a test run before decommissioning your old machine, lasting one day or more, until you are satisfied everything is working correctly. 

Please contact Visokio Support if you need further assistance.

Technical terms explained and their location

<USER_HOME>

This is user home directory of the user who has activated Omniscope. These are typically the following:

<INSTALLATION_LOCATION>

These are typical locations of where Omniscope has been installed.

<APP_DATA_VISOKIO>

This is location Omniscope uses to store user-specific settings.

NOTE: This location may be customised, depending on the changes in installconfig.properties (Windows / Mac OSX) or _launch.sh on Linux.