Migrating from older Sametime versions

This section describes the best practices for migration from an earlier Sametime release.

About this task

Side-by-Side Migration

  • Sametime 11 does not support in-place upgrades from earlier versions. Install and secure your environment on new hardware, then switch the users to the new server.
  • If the new server is part of the same Community as your existing servers, block port 1516 between the new server and existing server to prevent confusion while testing and validating new features. Prior to migrating, make sure port 1516 is open.
  • When installing the new server, it is important to keep the same directory type as the old server (LDAP or native Domino). If you choose a different type, the contact lists must be converted.

VPUSERINFO.NSF

  • Prior to the migration, it is recommended to purge stale users from the vpuserinfo.nsf. This can be done manually with a Lotuscript agent, or by using the NameChange utility. Domino database maintenance should be performed after purging stale users. This can be done in advance of the migration.
  • Consider pulling a replica of your existing vpuserinfo to the new environment, so that you can test the contact list and awareness using real data.
  • After copying vpuserinfo.nsf to the Sametime 11 server, replace the design of the database using the stuserin.ntf template. If you are replicating with an older server, change the replication settings to disallow replication of the design. The setting is in the Advanced replication properties - uncheck the option for Design elements.
  • It is recommended to upgrade the database ODS to match your Domino server version. See the Domino help center for details on Domino On-Disk Structure.
  • If you are changing directory types, for example, the old server is Domino native directory and the new one is LDAP, then you must convert the user's buddylist using the namechange utility.

SAMETIME.INI

  • You can migrate your tuning settings, for example for LDAP from the old server to the new server.
  • ST_COMMUNITY_ID should match the old server. This ensures the clients will show awareness properly after migrating.

Policies

  • Policies are configured in policies.user.xml, it is recommended to start your new server configuration with the policies.user.xml file that comes with the Sametime 11 install, and manually configure it. There are settings in the new server version that were not in the older versions of Sametime. See the topic Managing Policies.
  • If you are using managed-settings.xml, be sure to include it in the new policies.

Moving the Users

Once you are finished testing and are ready to migrate the users, there are a few different strategies to choose from.

  • Using the DNS. The hostname is the same and there is nothing additional to configure on the client side. In this scenario, the DNS would be changed to point to the new environment.
    • DNS may take some time to propagate throughout your network, thus you may need to leave both old and new servers running simultaneously for a period of time. Be certain you are replicating the vpuserinfo.nsf to keep the contacts up to date. You can check the stlog.nsf / Community Logins by Date to see how many users are still on the old server. Restarting the old servers periodically will also force users onto the new servers as soon as DNS is updated.
  • Using a load balancer. If your existing environment has a load balancer in front of it, you can simply add the new servers behind the load balancer and shut down the old servers.
  • Using the Sametime standalone Mux. If your existing environment has standalone multiplexers in the environment, you can upgrade your existing muxes in place to version 11, then point them at the new Sametime 11 servers when ready to migrate.
  • Pushing a new hostname using Managed-Community-Configs.xml. You can create the managed-community-configs.xml file and push it to the users using a Sametime Policy. The settings will take effect the next time a user restarts their client, it will be configured for the new hostname.

Have a Back Out Plan

This is a best practice for any migration. If your migration does not succeed, plan on having a back out strategy.