Preparing to Migrate to GVP 8.5

• Preliminary Steps
• Order of Migration
• Considerations for Multi-Tenant Migrations
• Interoperability Among Components

Preliminary Steps

The migration process includes the following preliminary steps for GVP 8.5:

1. Review the Migration Roadmap chapter of the Genesys Migration Guide.
2. Note the order in which the required Genesys software that is required for GVP 8.x should be upgraded. See Order of Migration.
3. Examine the component changes for GVP. See Changes in GVP 8.5.0.
   • The tables describe changes that directly affect the migration of this version.
   For complete information about what s new in the 8.5.x releases of GVP and how these releases function, see the Genesys Media Server 8.5 Deployment Guide. For a complete list of documentation relevant to the migration of this product, see "Reference Materials" a few paragraphs below.
4. Review the licensing requirements. Although GVP has no licensing requirements, there may be licensing requirements for associated products in the deployment, such as third-party speech engines or other Genesys components. For more information about Genesys licensing requirements, see the information about licensing migration in the Licensing Migration chapter of the Genesys Migration Guide.
5. Check the interoperability of the components of GVP 8.x during the upgrade procedures. See Interoperability Among Components.
6. Ensure that you have the required permissions to execute commands for GVP components in Genesys Administrator.

Reference

GVP 8.5 Deployment Guide GVP 8.5 User's Guide GVP 8.5 Configuration Options Reference GVP 8.1 Troubleshooting Guide

Media Server 8.5 Deployment Guide Media Server Configuration Options Reference GVP 8.1 Application Migration Guide VP Solution 8.1 Integration Guide

Order of Migration

The information in this section is specific to the application processes and components that enable or support all GVP 8.x releases.

Migrate or upgrade this GVP solution—including application components, other enabling software, and relevant data—in the following order:

Procedure: Prepare to Migrate to GVP 8.x

Prerequisites

• Present on your system: an installed version of GVP that is earlier than the version being installed.

Steps

1. [+] Migrate Management Framework

This update may not be mandatory. Consult the Genesys Interoperability Guide. However, Management Framework is the foundation for all Genesys products, solutions, and options.

Genesys highly recommends upgrading these Management Framework components before you install GVP. Refer to the table below for information on correct GVP version and component:

If migrating to this GVP version:	You need the Management Framework version of:
	Genesys Administrator	Configuration Server
8.5.1	8.1.3	8.1.3
8.5.0	8.1.3	8.1.3
8.1.7	8.1.3	8.1.3

For information about migrating the layers and components of Management Framework, see the Framework Migration part of this guide.

If you plan to upgrade Configuration Server, Genesys recommends that you first back up its configuration to an XML file.

2. [+] Upgrade other prerequisite Genesys components

Upgrade other prerequisite Genesys components (such as SIP Server, Composer), if required. Consult the Genesys Interoperability Guide.

When upgrading many components, determine if the first component you upgrade is backward compatible with the GVP components that have not been upgraded, yet. See at Genesys Interoperability Guide and the Genesys Supported Operating Environment Reference Guide.

3. [+] Back up the Configuration Layer

If you plan to upgrade Configuration Server, Genesys recommends that you first back up the Configuration Layer to an XML file. To do this:

1. Open the command console by selecting Start > Run, and then entering cmd.
2. Navigate to the Configuration Server directory for example:
   cd C:\Progam Files\GCTI\Multitenant Configuration Server
3. Execute the following command to export the configuration: confserv.exe -export <filename.xml>
   Tip

   If you are required to rollback to the original configuration after attempting the migration, you can use the confserv.exe –import <filename.xml> -user <account> -password <password> command to import <filename.xml> back into the Configuration Server directory. IVR Profile configurations are captured in the exported XML file. The <filename.xml> file is created in the same folder as the confserv.exe file. This is a useful backup, although it is not necessary to modify the IVR Profiles in any way to migrate to GVP 8.5.x.

4. [+] Back up GVP Application configurations

Back up the configurations of the existing GVP 8.x component Application objects.

5. [+] Update the Contact Center

You may need to update the contact center configuration; it must reflect changes in Place Groups, Agent Groups, and DNs, for example.

6. [+] Migrate GVP

This is a summary. See fully described and detailed steps in the procedure Steps to Migrate to GVP 8.5.x.

1. Stop GVP. (Hot migration is not supported.)
2. Uninstall the existing GVP 8.x components.
3. Create and configure new GVP 8.x Application objects, and install the GVP Applications on their hosts.
   

   FYI: Installing the the Media Control Platform also creates a shared directory... Windows: C:\var\www\gvp\mcp Linux: /var/www/gvp/mcp Windows automatically creates a virtual directory named mcp on the Internet Information Service (IIS) Web Server; it is really a pointer to the shared directory. For Linux, you must create the virtual directory manually following the Post-Installation Configuration of GVP Components: procedures in the GVP 8.5 Deployment Guide. Starting in version 8.1.4, the installation of the IIS web server is no longer required, because the ASR grammar that is hosted on the web server prior to 8.1.4 is now sent to the ASR engine as inline-grammar in the MRCP request. However, if the [mpc]inlinegrammar_by_url configuration option is set to true (default is falseINSERT_TEXT), the pre-8.1.4 behavior is restored and the user must set up the virtual directory correctly for speech recognition to work properly.

7. [+] Migrate the Reporting Server Database

1. Back up (always), then upgrade the database (only if needed). See Migrating the Reporting Server Databases.

8. [+] Verify the Installation

Start the newly installed version of GVP, and verify its proper operation by checking its log for errors.

Considerations for Multi-Tenant Migrations

GVP supports Hierarchical Multi-Tenancy (HMT) starting with release 8.1.2, enabling you to migrate your existing 7.6 multi-tenant configuration. The GVP 8.5 HMT model does not strictly replicate the GVP 7.6 model, however; there are many new features to enhance and simplify the way that multiple tenants are created, configured, and managed.

Tip

GVP and Genesys Administrator provide tools and wizards to facilitate migration.

This section discusses the six main aspects of migration to GVP: Tenant Hierarchy; Logical Resource Groups; DID Groups, DIDs, and IVR Profiles; Policies and Port Assignments; Speech Resource Management; and Server Data Retention Policies.

Tenant Hierarchy

Each GVP 8.1.2 (and later) tenant object, other than the default or root tenant, uses the parent TenantDBID to reference its parent tenant object. The root tenant resides at the top of the hierarchy and serves as the parent tenant. The root tenant is named Environment by default, but any name can be configured. All child tenants are created under the root or Environment tenant.

You can use the Bulk Tenant Wizard to migrate your existing hierarchy, which is described in the section "Migrating Your Existing Multi-Tenant Environment" in the Genesys Migration Guide. For more information about how to create and configure tenants in HMT, see Genesys Administrator 8.0.3 Help.

Logical Resource Groups

Beginning with GVP 8.1.x, Resource Groups represent groupings of resources that share common properties, such as, service type (i.e., voicexml), capabilities (i.e., support for a specific VoiceXML grammar), and method of load balancing (i.e., round-robin). They are an important element of resource management and essential for multi-tenant environment where specific resources and services may not be allocated to all tenants.

Unless you are migrating from GVP 8.1.1, there is no resource group data to migrate. Resource Groups did not exist in GVP 8.1.0 and earlier 8.x versions. For information about how to create Resource Groups, see the GVP 8.5 Deployment Guide.

How the LRGMT Migrates Legacy Resource Groups

The Logical Resource Group Migration Tool (LRGMT) is an application within Genesys Administrator that is invoked from the operating system's Command Line Console (CLC), and provides diagnostic information directly to the console. The tool accepts command-line arguments, which correspond to the fields in the Genesys Administrator login dialog box, and must be specified in the following order:

• <username>
• <password>
• <application>
• <host>
• <port>

Upon completion of the migration process, the tool exits without user intervention and provides any error messages to standard error log file.

The tool enumerates all of the resource groups that are in the legacy format and are not Gateway resource groups, and creates new groups by using the Configuration Unit (CU) scheme (Management Framework objects).

Legacy resource groups belong to the Environment tenant by default, therefore, the new resource groups are created under the Environment tenant. When a new resource group is created without errors, the associated legacy resource group is deleted.

To compare resource groups, the tool uses two kinds of information:

• The virtual IP that is configured for the Resource Manager Application to which the resource group belongs.
• The connections to the Resource Manager Application for the specific resource group.

Based on this comparison, identical pairs of resource groups are considered to belong to a Resource Manager High Availability (HA) pair. The tool creates only one new resource group for these LRGs and assigns the CU to both Resource Manager instances in the HA pair.

DID Groups, DIDs, and IVR Profiles

Direct Inward Dialing (DID) Groups are used to group DID numbers or DID ranges and can have IVR Profiles associated with them. (DIDs were previously referred to as Dialed Numbers [DN]). A child tenant can have more than one DID Group and the tenant owner of a DID Group can assign more than one DID Group to its child tenant. The rules for adding DID ranges to DID Groups remains the same as it did for DNs in previous versions of GVP, except that DIDs must be unique across all tenants rather than the parent tenant only.

Starting in GVP 8.1.4, you can install Policy Server to validate DID Groups and detect overlaps in DID ranges. It provides this information in response to HTTP queries from Genesys Administrator. For information about how Policy Server performs it s functions, see the GVP 8.5 Deployment Guide.

You can use the Bulk Operations Wizard to migrate your existing hierarchy, which is described in the section Procedure to Migrate Multi-Tenant Configurations, found in the chapter Migration Procedures for GVP 7.6 and VG 7.x, in the Genesys Migration Guide. For more information about how to create DID Groups, see the GVP 8.5 Deployment Guide or Genesys Administrator 8.1 Help.

Policies and Port Assignments

Port levels 1, 2, and 3, previously provisioned at the customer level, can now be provisioned for tenants (at any level of the hierarchy) or for an IVR Profile.

The number of concurrent calls allowed for each port and the affect on system performance remains the same in 8.1.2, however, the values are now configured in the gvp.policy/usage-limits, gvp.policy/level2-burst-limit, and gvp.policy/level3-burst-limit options.

You can install Policy Server to validate and resolve GVP-specific business rules (the policies that are enforced by the Resource Manager). For information about how Policy Server performs it s functions, see the GVP 8.5 Deployment Guide.

You can migrate the maximum ports provisioning data for your 7.6 IVR Profiles to the gvp.policy/usage-limits option. Also, if you define the gvp.policy/level2-burst-limit, and gvp.policy/level3-burst-limit options when creating your IVR Profiles, the functionality is the same as when they are provisioned for a tenant. Open the Genesys Migration Guide and search for "Procedure to Migrate Multi-Tenant Configurations."

Tip

In GVP 8.1.2 and later, the usage-limit, permission, and rule-based policies are checked using top-down methodology. While the way in which the usage-limit and rule-based policies are checked is transparent to the user, it is important to note that if you are migrating IVR Profiles with permission policies (for example, conference-allowed) that are defined in both the profile and tenant, the IVR Profile will not be checked in the new 8.1.2 hierarchy before the tenant (bottom-up). In other words, the profile-defined permissions could be overridden by the tenant-defined permissions.

For more information about how GVP 8.1.2 and later supports policies and port provisioning in HMT, see the GVP 8.5 Deployment Guide.

Speech Resource Management

Starting in GVP 8.1.4, you can install the MRCP Proxy to manages access and routing to your MRCPv1 resources. The MRCP Proxy can route requests to the supported resources, provide round-robin load balancing, and monitors the health status of resources. For information about how the MRCP Proxy performs its functions, see the GVP 8.5 Deployment Guide.

Reporting Server Data Retention Policies

After you have installed the Reporting Server, you can use the Data Retention Policy Wizard to configure four categories of tenants and IVR Profile data retention policies CDR, Operation Reporting, VAR, and Service Quality.

For information about how to use the Data Retention Policy Wizard, see the GVP 8.5 User's Guide.

Interoperability Among Components

The term interoperable means that different versions of Genesys solutions, components, or options can work together during the migration process.

Interoperability of Genesys products can occur at two levels of migration:

• Interoperability at the suite level means combining different releases of solutions and options during the migration process.
  Example: You can migrate to the Management Layer of Framework 8.0.1 while still using 7.x or 8.0 components. For information about suite-level interoperability, see the Genesys Interoperability Guide.
• Interoperability at the solution level means combining different releases of the components of a particular solution while upgrading them sequentially during the migration process.

The mixture of components may include the executable files, applications, routing strategies, scripts, and data that make up a particular solution.

As you upgrade each of the components in sequence, you will need to know whether it is backward-compatible with the other components of GVP.

Example: If you have four components to upgrade, determine whether the first component you upgrade to release 8.1 will be backward-compatible with the three 8.0 components you have not yet upgraded.