Migrating to Cisco Unity Connection 10.x from Another Voice-Messaging System
Note For detailed information on migrating from Cisco Unity to Cisco Unity Connection, see the “Migrating from Cisco Unity to Cisco Unity Connection 10.x” chapter.
When the customer is replacing another voice messaging system with Unity Connection, consider the following issues:
- How do users interact with each system? For example, the options offered by the Unity Connection standard conversation (the telephone user interface, or TUI) and the key presses used to accomplish tasks may be different from what users are accustomed to using. As an alternative to the standard conversation, some customers may want to activate Optional Conversation 1 (the ARIA-like conversation available in Unity Connection) so that users hear message-retrieval menus that more closely resemble the choices they are familiar with. However, other menus—those that outside callers and Unity Connection users use to send and manage messages, as well as the menus that users use to change their Unity Connection settings—are the same as those in the standard conversation.
- Ensure that the customer understands the Unity Connection behaviors that are different from those of the voice messaging system it is replacing. For example, if the customer does not currently use an automated attendant feature and wants Unity Connection to be configured the same way, this should be noted so that the installer configures Unity Connection correctly. If it is necessary to make changes, for example to change the behavior of the opening greeting, or to zero out to an operator option during a personal greeting, these changes should be made and tested prior to the day of the cutover.
- Plan a method for creating Unity Connection users. Will they be imported from an LDAP directory, imported from Cisco Unified Communications Manager, imported from a CSV file, or added using Cisco Unity Connection Administration? If they will be imported from a CSV file or added using Unity Connection Administration, where will the information come from? Creating user accounts requires planning and testing prior to the cutover.
- The larger the installation or number of servers, the greater the need to perform user enrollment tasks prior to the day of the cutover. If too many users try to enroll simultaneously, some users (up to the number of voice ports available) will succeed in accessing the Unity Connection server and enrolling, but the rest will get a busy signal.
To prevent this negative user experience, smaller groups of users should be told a few days in advance how to call the pilot number and enroll in Unity Connection before the system goes live.
- If the customer has special audio-text applications set up in the existing voice messaging system, Unity Connection equivalents should be planned and set up before cutover. Unity Connection supports audio-text applications and provides tools for designing and configuring them.
- Unity Connection does not support group mailboxes, but the same functionality can be made available by setting up a call handler whose greeting prompts the caller to “press 1 for Pat, press 2 for Chris,” and so on. Dispatch messages may also provide the necessary functionality needed to support group mailboxes. (For more information about dispatch messaging, see the “Dispatch Messages” section of the “Messaging” chapter in the System Administration Guide for Cisco Unity Connection Release 10.x, at http://www.cisco.com/en/US/docs/voice_ip_comm/connection/10x/administration/guide/10xcucsagx/10xcucsag110.html.
- When the Unity Connection design is finalized and verified through lab qualification, Unity Connection functionality should also be tested before cutover running a simulated load test and by running application test plans.