Migrating to Cisco Unity Connection 9.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 9.x” chapter.
When the customer is replacing another voice messaging system with Cisco Unity Connection, consider the following issues:
- How do users interact with each system? For example, the options offered by the 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 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 Connection users use to send and manage messages, as well as the menus that users use to change their Connection settings—are the same as those in the standard conversation.
- Ensure that the customer understands the 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 Connection to be configured the same way, this should be noted so that the installer configures 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 Connection users. Will they be imported from an LDAP directory, imported from Cisco Unified Communications Manager, imported from a CSV file, or added by using Cisco Unity Connection Administration? If they will be imported from a CSV file or added by using 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 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 Connection before the system goes live.
- If the customer has special audio-text applications set up in the existing voice messaging system, Connection equivalents should be planned and set up before cutover. Connection supports audio-text applications and provides tools for designing and configuring them.
- 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 in Cisco Unity Connection 9.x” section in the “ Messaging in Cisco Unity Connection 9.x ” chapter of the System Administration Guide for Cisco Unity Connection Release 9.x, at http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx.html.)
- When the Connection design is finalized and verified through lab qualification, Connection functionality should also be tested before cutover by running a simulated load test and by running application test plans.