Jump to: navigation, search

Preparing to Migrate to GVP 8.5

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

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
2. [+] Upgrade other prerequisite Genesys components
3. [+] Back up the Configuration Layer
4. [+] Back up GVP Application configurations
5. [+] Update the Contact Center
6. [+] Migrate GVP
7. [+] Migrate the Reporting Server Database
8. [+] Verify the Installation

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.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on July 11, 2018, at 00:48.