Moving or Migrating DX UIM Installation from old environment to a new one (Physical or Virtual)
search cancel

Moving or Migrating DX UIM Installation from old environment to a new one (Physical or Virtual)


Article ID: 34382


Updated On:


DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)


How do I move or migrate my DX UIM (Nimsoft) installation to new servers?


  • This information is generally applicable to all versions of UIM.


  • UIM migration guidance


Moving the Nimsoft installation generally requires making a copy of the old and moving it to the new.

However some steps need to be taken before the move.

  • Are you going to need to change the IP Address, or host name of the hub?

    • If so, you are going to need to merge all of the QoS data collected by the old hub into the QoS collected by the new hub. This will be true for any QoS with source name of the old hub.

    • The best option (if possible), is to keep the same server name and IP address. It has been found that even using the same hostname but with different upper/lower case may cause issues.

  • If you have tunnels between hubs and will be changing the hub name, or ip address you will need to recreate the tunnels. This will require some downtime for each subordinate hub.

  • Try to make sure that both your data_engine queue and the nas queue are empty before you copy the files.

To backup the hub:

1. Stop the Nimsoft Robot on the hub to be moved

2. Backup the entire directory

- Windows C:\Program Files (x86)\Nimsoft

- Linux /opt/nimsoft

If you cannot afford the downtime:

a. Stop the data_engine, nas, wasp and sla_engine probes. This should stop any SQL clients from connecting to the database.

b. If possible, stop all QoS data from being inserted into the data_engine queue. This can be done by moving all of the robots connecting to the existing hub to another hub and then stopping any probes running on that hub.

3. Copy the Nimsoft directory to the new server

- Windows C:\Program Files (x86)\Nimsoft

- Linux /opt/nimsoft

4. Install the same version of Nimsoft that was on the old server onto the new server

a. This step will maintain the current configuration files, but register all of the probes

b. If feasible, do not change the userid, or password of the user accessing the database during this install. Keep all of the default values and its install should work perfectly.

5. Post-move

a. Reestablish hub tunnels

b. Reestablish nas replication

c. Activate any probes not already activated

6. If the hub does not start correctly, or you lose contact with the other hubs you might need these steps, but: ONLY IF YOU HAVE MULTIPLE HUBS

a. Stop the Nimsoft Robot on the new hub

b. Remove the security.cfg, security.dta, and security.bak from the hub directory

   - Windows C:\Program Files (x86)\Nimsoft
   - Linux /opt/nimsoft/hub

c. Start the Nimsoft Robot

d. Allow it to run for at least 5 minutes before trying to log in again

Be sure to check and keep software compatibility in mind when considering using this process

Compatibility Matrix as of 20.4:

Upgrade Path as of 20.4:

Additional Information

If server names and IP addresses will be changed to new hostnames and IPs, consider the following:

  1. Take a backup / SNAPSHOT of the Primary Hub, OC and CABI machines, and Database servers

  2. If possible, install a similar UIM version to what you are currently running on the new server

  3. Stop the Nimsoft Robot service

  4. Copy the contents of the old ...Program files (x86)\Nimsoft installation directory to the new server into whatever location you need e.g., for Windows, C: drive, D:\ drive, for Linux/UNIX, /opt/nimsoft,etc.

  5. Delete the contents of the niscache directory

  6. Edit the robot.cfg and hub.cfg files to reflect the new server names and new IP addresses

  7. If you want you can edit the controller.cfg and set all the probes listed there to 'active = no' except the controller/spooler/hdb/hub to prevent them from starting while you make configuration changes

  8. Then start the Nimsoft Robot Service on the new servers, Primary, Secondary (HA), OC, CABI, etc.

  9. You can verify that things are working and IM should be functional and able to connect to the hub on the new server

  10. Note that one or more remote monitoring probes might have references in them to the wrong locations. You can edit their .cfg file directly to change them or use the probe GUI in IM to edit and then activate them one at a time


  • Depending on your underlying database, you need to go through whatever process is appropriate for that to move it or create a copy. 
  • Then you need to update the data_engine probe with any new connection info.
  • If you use templates that store their configuration in the database moving them is more difficult unless you take the whole database along with the move.


  • Similarly, if you have certificates tied to the machine name, when you move wasp to the new server those certs might become invalid since they use the 'old' host name. You would have to generate and setup the new certs.

Helpful References:

Move CABI to different server (

Automatically validate hdb and spooler probes or other probes via script 

 Wasp fails to start and throws error a child container failed during start