Planning for migration

Migration covers a number of scenarios.

  • Upgrading versions. When you upgrade from a prior release, the installation and startup process will handle migrating any configuration or data that may have changed between versions. See Installing the HCL Traveler server for more information on upgrading a server.
  • Moving to a new server. It is possible to move the server data from one physical machine to another.
  • Integrating stand alone HCL Traveler servers into a high availability pool. In this process, the local data from each servers is transferred to the shared enterprise database of the High Availability (HA) pool.

Upgrading versions

Any existing HCL Traveler server can be upgraded to the current release. The installation and start up process handles the migration of configuration information and the upgrading of existing internal databases. If you are upgrading Domino too, upgrade Domino first and then Traveler. It is always good practice to maintain a pilot environment to test upgrade and migration prior to deploying in production. For more detailed information, see Upgrade considerations and overview.

If you are upgrading servers in an HA environment, best practice is to upgrade one server at a time. Then, any data or database migration occurs while the other Traveler servers continue to function normally. Only continue to upgrade the next server when the current one has fully started,Doing this ensures continued service for any Traveler users. For more information, refer to Upgrade considerations for a Highly Available environment. Although not common, additional migration steps may be required on an HA environment if you chose to manually manage your database schema. For more information, see Updating the enterprise database.

For standalone servers, the upgrade process requires an outage. The length of the outage depends on the Traveler release being upgraded and the number of devices the server services. Refer to the following table for estimated times to upgrade a standalone server to the current maintenance level based on these factors. Keep in mind that these are estimates and best practice is to use a pilot server to determine actual upgrade times in your environment. Note that a standalone server can be integrated into an HA environment at any time, if desired. For more information, see Integrating HCL Traveler servers into a High Availability (HA) pool.
Table 1. Estimated upgrade times for standalone Traveler servers
Number of devices Outage time for 8.5.3.x upgrade Outage time for 9.0.1.x upgrade Outage time for 10.0.x upgrade
< 100 45 minutes 15 minutes 10 minutes
500 90 minutes 30 minutes 15 minutes
> 500 120 minutes 45 minutes 20 minutes