Moving to a new server

A server migration transfers an existing myContactCenter installation with its Agents, skills, flows, conversations, statistics and license data. Install the programs on the destination computer and transfer the existing databases and required files. A new installation with empty databases does not restore this data.

Plan a maintenance window: the contact center is unavailable during the final backup and switchover. Finish active conversations beforehand and inform the Agents.

1. Define the scope and rollback plan

Before the move, record the installed version, computer names, SQL instances and database names, service accounts, Dispatchers and file locations. Decide which components will actually move:

Keeping the DNS name unchanged can avoid updates at workstations. Still check that it resolves to the correct computer after the switchover. The server name, SQL instance and registration point are different addresses; changing one does not change the others. See Names and addresses.

Where possible, install the same version on the destination system for the move. Perform an additional version update as a separate step and first check which versions work together. The Server Configurator and the Server can update the database schema when they start; an older program version is not a guaranteed rollback option after that.

2. Back up databases and files

First back up a test snapshot so that you can check restoration on the destination system in advance. For the final transfer:

1. Close Agents and Wallboards. Stop the old Routing Services so that no new calls, emails, chats or callbacks are processed.
2. Stop the old myContactCenter Server and the other affected services. For a master/standby setup, also account for its services and synchronization.
3. Use the tools of the respective database system to create a full backup of the configuration database and the Monitoring Database from this stopped state.
4. Back up the SQL logins or PostgreSQL roles and the files listed below. Record which backups belong together.

The configuration database contains, among other things, Agents, administrators, skills, flows, statistics and license data. The Monitoring Database contains tickets and conversation data. If a database remains on its existing database server, you do not need to copy it to the new myContactCenter computer; it still needs a current backup.

Create backup in the Administration only backs up the configuration database, not a complete installation. Restore it using the tools of the database system; see Backing up and maintaining the database.

Announcements and music are stored in the local MediaPool of the Routing Service. Include this directory in your inventory. The available directories and the locations where programs store their settings are described in Folders, files and logs and Settings files.

3. Prepare databases and users on the destination system

If the databases move, first restore the backed-up databases on the new database servers. Later, select exactly these databases in the Server Configurator. Do not use a new, empty database instead of the restored database.

Microsoft SQL Server

A backup of a user database contains its database users and permissions, but not the matching SQL logins of the instance. When moving to another instance, the logins must also exist there and match the restored users. For SQL logins, having the same name is not enough: SQL Server maps them to each other using an identifier, the SID.

Distinguish these accounts:

In the operation described here, the Windows service account does not replace the SQL login of the Server. The SQL login entered in the configurator must remain available after installation. The SQL instance must allow SQL Server authentication; see Microsoft SQL Server.

During the SQL migration, have the required SQL logins transferred with their SID and password information, or map existing database users to the correct login. For a local Windows account, the account on the new computer is a different identity from the account of the same name on the old computer. An unchanged domain account avoids this identity change; its permissions on the destination computer must still be correct.

For a targeted check, this query shows the users and their direct mapping to instance logins in the respective myContactCenter database. Appropriate SQL administration permissions are needed to display all required logins:

SELECT
    databaseUser.name AS DatabaseUser,
    databaseUser.type_desc AS UserType,
    serverLogin.name AS ServerLogin
FROM sys.database_principals AS databaseUser
LEFT JOIN sys.server_principals AS serverLogin
    ON databaseUser.sid = serverLogin.sid
WHERE databaseUser.principal_id > 4
    AND databaseUser.type IN ('S', 'U', 'G')
    AND databaseUser.authentication_type_desc IN ('INSTANCE', 'WINDOWS');

A missing ServerLogin is a reason to check the mapping; the query checks neither passwords nor all access permissions. For Windows access, group memberships must also be considered.

If a suitable login already exists, an existing database user can be mapped to it. Example for a service account user: execute the statement only in the affected database and replace both names with your actual names.

ALTER USER [mycc-service] WITH LOGIN = [DOMAIN\mycc-service];

Then check the required database roles. Do not delete users or logins indiscriminately. Microsoft provides details on transferring SQL logins and fixing orphaned users: Transfer logins between instances and troubleshoot orphaned users.

Monitoring Database on PostgreSQL

In addition to the database, back up and transfer the required roles, owners and permissions. A single pg_dump does not transfer global roles; for these, you can use pg_dumpall --globals-only. Review the generated export before applying it to a destination system that is already in use. See PostgreSQL: pg_dumpall.

The Server uses the PostgreSQL access entered in the configurator. Setup also configures ownership and permissions for the product role myContactCenterTicket. Check that required roles already exist for the restoration and that ownership and table and sequence permissions are correct. After the move, you must be able both to read existing tickets and to save new conversations.

4. Set up programs and services on the new computer

1. Check the requirements and install the required packages on the destination computer.
2. In the Server Configurator, select the existing or restored configuration database and Monitoring Database. Enter the SQL Server name so that workstations can reach it too; localhost or . are unsuitable for this.
3. Enter the Windows service account and its password. For a local account, use the account of the new computer. Also check its access to shares and, where applicable, to the Swyx configuration.
4. Complete the wizard from Start through to Finish. Then check its log and the Windows Event Viewer. A completion page alone does not prove that all database commands succeeded.
5. Use their configurators to set up the other services being moved: Dispatcher, Logger and Routing Service. Keep the new Routing Service stopped until the server configuration has been checked and the planned start of operation has been reached.

Detailed setup is described in Setting up the server and Dispatcher, Logger and Routing Service. Transfer any required local special settings from the backed-up settings files. Edit these files only while the service is stopped; do not copy old computer names and local accounts without checking them.

Check DNS and firewalls between the actual components. This includes direct SQL access from workstations and, for a distributed Routing Service, 6009/TCP on the myContactCenter Server; the Server package does not open this port itself. The full overview is in Ports and connections.

5. Update server addresses and paths

Start the Administration and connect using the new server name via Add Server. Log in with an existing administrator account from the transferred database. The credentials of a new installation do not automatically apply to a transferred database; see Starting and logging in.

Dispatcher and server configuration

Server addresses are stored in two different places:

1. In the Dispatcher Configurator: Master server and Standby server. Update these entries in each Dispatcher and complete the configurator through to Finish.
2. In the server configuration of the Administration, Standby tab, Contact center server group: Master, Standby, Alternative name for Master and Alternative name for Standby. These values are stored in the transferred database, so they may initially still contain the old addresses. Check and save the addresses of the destination system. This requires the Dispatcher permission.

For a single server, Master and Standby point to the same new server. The Dispatcher gives clients the addresses from the server configuration. Changing only the computer name in the Dispatcher is therefore not enough.

File locations and connections

Check in the Administration:

• Server › Path for storing recordings: transfer the existing folder or enter a new reachable folder. The Routing Service needs access to it. Also check playback of existing recordings; changing a path does not move any files.
• Server › Path to store reports: transfer existing files and ensure write access for the new Server.
• PBX: phone system and login. Even if the phone system remains unchanged, service account permissions and allowed source addresses may change.
• Email delivery, mailboxes, external databases and custom flows and scripts: check stored computer names, shares and local paths.
• Licenses › Activation: changing computers can require a new activation due to Activation after hardware has changed significantly. Transferring the license database does not replace this check; see Activation.

For recordings and voicemails, the Monitoring Database stores the file path of each recording. A new Path for storing recordings applies to new recordings; it does not automatically rewrite references to old files. Keep the previous paths accessible to the new Routing Service, or coordinate an update of the stored file references with Support. Pay particular attention to recordings in the local Recording folder because a share was unavailable.

Access and storage are described in Server tab, Phone system and External databases.

6. Update clients and other components

Close the affected clients and restart them after the switchover. When distributing defaults in the Agent program directory, remember that they do not replace registration points already entered for a user. Therefore also check existing user profiles and terminal server sessions; see Defaults for all users.

If the Routing Service also moves to another computer or network, check its SIP account and, where applicable, PublicAddress and BindAddress. These values are in its settings file.

7. Start operation and complete acceptance

Start the Server and Dispatcher, followed by the Logger and Routing Service, and log the clients in to the destination system. The old production installation remains stopped. Work through these checks with a test Agent:

• Status of services shows the expected computers and services Online; the Routing Service is registered with the PBX.
• Agent and Administration connect to the new Server. Check at least one existing workstation, not only a newly configured one.
• Incoming and outgoing calls work with audio in both directions; greetings and routing use the expected flows.
• A historical report and a statistics dashboard read the transferred data at the workstation. An automatic report can be generated, saved and sent on the Server.
• Existing tickets and conversations can be read. A new contact is saved in the correct Monitoring Database.
• Old voicemails or recordings can be played back; a new recording can be saved and played back.
• Email, fax, chat and callback functions in use work, including the website connection. Custom interfaces and external databases are reachable.
• License status, Logger log and Windows Event Viewer contain no unresolved errors caused by the move.

Then check the regular backups of both databases and file locations at the new location. Decommission the old computer only after documented acceptance. If problems occur, consult Status of services and Troubleshooting.

If you need to roll back

First stop the new installation. Restore the old server and Dispatcher addresses or DNS mappings, and use a consistent database and file snapshot that matches the old program version.

If production contacts have already been processed on the new system, they are missing from the backup taken before the move. Email delivery, callbacks and recordings may also differ. Before rolling back, therefore clarify with Support how to preserve this new data; simply restoring the old backup can lose data or cause contacts that have already been processed to be processed again.