A PRACTICAL GUIDE TO EVALUATING NEW VOICEMAIL REPLACEMENT SYSTEMS

A PRACTICAL GUIDE TO EVALUATING NEW VOICEMAIL REPLACEMENT SYSTEMS BY DAVE BALLINS

2

TABLE OF CONTENTS NINE KEY AREAS OF DATA COLLECTION...... 5 MIGRATION BEST PRACTICES...... 8 RFP Sample Use Case...... 8 Migration Options...... 8 Risks...... 10 Esna Recommendations...... 10 APPENDIX 1: REPLICATION OF EXISTING FEATURES AND FUNCTIONALITY...... 12 APPENDIX 2: VOICE SYSTEMS AND/OR PBX INTEGRATIONS...... 13 APPENDIX 3: ARCHITECTURE...... 14 APPENDIX 4: RESILIENCY AND SCALE...... 15 APPENDIX 5: INTEGRATION WITH BUSINESS APPLICATIONS...... 16 APPENDIX 6: CLIENT INTEGRATIONS...... 17 APPENDIX 7: DESIGN AND IMPLEMENTATION EXPERTISE...... 18 APPENDIX 8: SUPPORTABILITY...... 19 APPENDIX 9: FINANCIAL...... 20 CONTACTING ESNA...... 21 www.esna.com 3

THIS IS A PRACTICAL GUIDE TO EVALUATING, UPGRADING AND REPLACING VOICE MAIL SYSTEMS. THE PURPOSE OF THIS GUIDE IS TO PROVIDE A FRAMEWORK FOR EVALUATION AND MIGRATION. A CTO of a major Colorado University recently said, voicemail is a parity technology, it only keeps our university at parity with other institutions. It doesn t bring us more students, better educators or more research grants, thus we no longer consider Voicemail to be a strategic communication tool. Many communications technologies such as fax or fax messaging and voice mail usage are declining. However, institutions and businesses are not ready to remove either in the foreseeable future. This document provides a framework for evaluating options and vendors when upgrading or replacing your proprietary voice mail systems with minimum cost and disruption. We will focus on nine key areas which are core to any successful, legacy voice messaging systems migration. Nine Key Areas of Evaluation 1. Replication of Existing Features and Functionality 2. Voice Systems/PBX Integrations 3. Architecture 4. Resiliency and Scale 5. Integration with Business Applications 6. Integrations with Clients 7. Design and Implementation Expertise 8. Supportability and Ongoing Software Assurance 9. Financial Considerations and Options Beyond these nine areas of evaluation we recommend you leverage a trusted partner or consultant who has intimate knowledge of your enterprise, business culture and processes. 4

This guide will not replace a comprehensive strategic analysis of the needs of your particular enterprise. This guide provides a framework for gathering relevant information that can later be used to evaluate competitive offers and help ensure a seamless deployment of your next generation voicemail or unified communication and collaboration solution. The appendix includes vendor evaluation forms. Blank line items have also been included as a means of adding questions that are more specific to your own enterprise. NINE KEY AREAS OF DATA COLLECTION This is a practical guide that provides a framework for replacing, upgrading and migrating existing voice mail systems. This guide evaluates nine areas of consideration. 1. Replication of Existing Features and Functionality Users hate change, so successful migrations ensure existing features, functionality and user experiences are preserved. In this area, there can be a myriad of features to compare and contrast and it is recommended that you ask your vendor for a feature comparison matrix that clearly outlines all of their system s user capabilities. There are two primary considerations in replicating caller and user experience: Replication of existing Telephone User Interfaces (TUIs) Replication of existing touch tone or speech enabled auto attendants Other questions to consider Does your solution provider have a selection of TUIs that can be assigned by user or groups of users? What if your TUI doesn t exactly emulate my existing experience? Does your system provide me with a way of modifying the TUI myself? Are there any restrictions on your auto attendant menus? Can I program them so that they can answer differently by time of day, day of week or holiday schedules or replace my existing call center greetings? Does your solution natively support fax or do I need another server? www.esna.com 5

2. Telephone Systems and/or PBX Integrations The future of your enterprise voice strategy may not always be clear. Today you may be on a TDM Avaya PBX but tomorrow you may merge with another company that utilizes a Cisco VoIP solution, or migrate to another manufacturer s PBX platform In either event, it s not enough to just ensure you can integrate your new voicemail solution to your existing PBX platform. It is also essential the solution you choose be able to integrate with any current or next generation platform. 3. Architecture Architectural flexibility is essential. While many manufacturers are moving to open standards and virtualization, many companies still require that a solution be capable of being deployed in either a traditional Telecom standalone server configuration or as a fully integrated business application running in an open standards/virtual environment, either on premise or in the cloud. 4. Resiliency and Scale Voice messaging is a single application but during this time of transition, enterprises often take the opportunity to reduce costs by combining other, related legacy voice applications like Right Fax, Nuance Speech attendants or mass notification apps into a single common platform. So whether you are replacing a large enterprise or campus-wide voice messaging system, or whether you are looking to flatten and consolidate a collection of static voice applications on to a single server, resiliency and scale can be important considerations. With this in mind, the solution must be able to be deployed like any other IT solution with either single site, geo redundant and/or High Availability configurations. 5. Integration with Business Applications Voice mail solutions must integrate not only with phone systems, but also provide rich integration into the applications where users live and work, such as Cisco WebEx, Google Apps, Microsoft Office 365, Jive and Salesforce.com. Along with the move to the cloud comes the notion that access to and consumption of business applications is rapidly moving from thick clients loaded on desktops to mobile devices and browsers. 6

6. Integrations with 3rd Party Client Collaboration Solutions Many companies are already employing collaboration clients from Cisco, Microsoft and Google to provide a common Unified Communications (UC) experience. The ability to deliver messaging content or other UC functionality into the environments where users live and work is critical for success. Therefore, it is important to assess whether or not your new voicemail replacement solution will integrate within existing manufacturer s UC clients or whether they will provide a similar native experience. 7. Design and Implementation Expertise On time, in scope and on budget deployments are predicated on your provider s ability to access current and future requirements associated with replacing the legacy voice mail system. Checklist items like past experience, installation staffing (onsite vs. remote), will be left to assessment outside of this guide. Asking for reference customers is recommended. 8. Supportability and Ongoing Software Assurance Historically, companies like OCTel, VMX or even AT&T provided migration tools that allowed enterprises to migrate data and apps from one proprietary platform to another. Even though replacing a voice mail system with a new solution is often referred to as a simple migration, it is not. Many licensing promotions or retention offers that position a simple migration from a legacy system to a new solution may make it appear that you are merely upgrading your existing platform, the simple truth is that you are not. Your migration will almost certainly include a move from a proprietary or manufacturer-provided hardware system to a new manufacturer or open source platform that has no commonality in terms of operating system or administrative interface to your existing system. Thus, you will need to consider new models for software, hardware and administrative support and training. 9. Financial Considerations and Options Beyond the actual dollars and cents comparisons between vendors, it is important that both operating and capital expenditure models be made available to meet the changing consumption needs of the enterprise. www.esna.com 7

MIGRATION BEST PRACTICES RFP Sample Use Case Objective: A world renowned healthcare facility was replacing and upgrading three OCTel messaging servers integrated into multiple Nortel PBXs including a complex infrastructure with: One networked, integrated, voice mail system with unified messaging in three different sites, with fully redundant systems. The new system must be designed to have no single point of failure, serve multiple hospitals, have SIP connectivity between sites and the user interface experience shall appear the same as the displaced Octel systems. System wide capability to integrate and scale across different telephone platforms including but not limited to: AVAYA, Nortel, NEC, CISCO etc. The capability to preserve the user experience (TUI) for the various platforms. The CUSTOMER s expressed intent was to be exposed to as little risk as possible during the process of migrating end user mailbox content and metadata, auto attendant structures and recordings, forms mailbox applications as well as the messages, names and greetings from the three existing OCTel 250 platforms. The following are Esna s responses to the RFP. Migration Options In 1995 OCTel introduced the O250 series. It was developed to replace the Aspen/Maxim Line of OCTel servers. To accommodate migrations from the A/M line, OCTel developed a Silver Suitcase migration tool. This tool enabled A/M users to migrate in a mirrored fashion, ALL database content including User and Callers interfaces and application. In essence this tool enabled the legacy OCTel user to port a mirrored image of their server to the new O250 environment. This migration was tested and provided for a secure and proven method of migrating all user and callers applications and associated data. Today, no such tool exists. Today, there are server tools/utilities that can be employed to tactically address different aspects of the migration but there is no silver suitcase that can be employed to address a comprehensive migration of all user and caller focused applications and data. Options now can be broken down into several categories: 8

Migration of User Data: Avaya, Mutare and Common Voices each have a tool that can be used to migrate messages, names and greetings from the O250 environment to any 3rd party server or service. Most require a minimum 3.1.1.x software release of the OCtel system as well as feature activation and a LAN card installed in each system for the tools to be able to pull the messages, greetings and names from the system. All are focused only on the Type 0 mailbox and all will require the mailbox passwords to be stripped and set to a default for access to the actual stored messages in the mailboxes. Callers Menus and Voice Forms: As we have done with a major federal client, customer or professionally recorded greetings for caller s menus, voice forms or other callers apps (e.g. IVR apps) can be extracted by playing and re-recording greetings, names and scripting to meet the CUSTOMER s current requirements. Telephone User Interfaces: Most companies offer the ability to emulate or provide Aria Like interfaces from the administrative interface. Only one company, Esna, provides a TUI builder utility that actually provides a GUI interface that will enable the systems administrator to modify an existing or create a custom TUI for any user or group of users natively from the admin MMC. Message Migration Only: Set up AMIS networking between the OCTel systems and the new voicemail/us system and allow the end users to forward their own important messages VIA AMIS networking to their new voicemail box on the new UC system. Once on that system, messages can be delivered to their email and stored on a local hard drive, removable storage, SAN, etc. www.esna.com 9

Risks For ALL Option 1 Processes: All systems will require multiple restarts to enable the features and install the LAN cards Any restart will introduce the risk of hardware failure due to the age of the components. The chance of failure in this case is tripled since there are 3 servers Once passwords are stripped, there is no fall back to a restoration point before the migration process began. Messages that are extracted may be lost forever. Stripping mailbox passwords leaves the system exposed to unauthorized access to mailboxes and messages and potentially sensitive patient or employee data Stripping of mailbox passwords makes a staged migration more of a security risk because you would still have to allow outside access to the system until all of the users had been migrated. Esna Recommendations Avaya has leveraged their relationship as a Master Distributor with Esna on several occasions to meet the needs of OCTel customers with a requirement to move to a highly scalable replacement for existing OCTel technology. In doing so, Avaya sold these solutions directly to these risk adverse federal agencies and relied on Esna to provide a migration solution that meets the needs of these customers who like you, demanded minimization of risk, the assurance of business continuity and also the assurance that mission critical applications and data would be preserved during the transition process. There are many examples of Avaya selling Esna s Officelinx platforms to enterprise class OCTel customers including a large federal government body and the Federal Aviation Administration. Both of these customers have been installed for nearly four years, are highly referenceable and have not had one minute of systems unavailability. In each case these users had specific requirement to preserve data but, as you might expect, security and data loss protection were primary drivers for selecting the proper methodology for recreating the OCTel environment on the new Esna Platform. 10

While Esna could employ any or all of the above migration options, it is suggested that based on the risk factors above and past experience with Avaya/OCTel customers that the following migration plan be utilized: Callers Menus and Voice Forms: A complete audit of all callers and voice forms applications to be completed to insure that all existing apps are still in use and/or if based on utilization, modifications need to be made to better address the current needs of CUSTOMER. Once the audit has been completed, changes will be made on the existing OCTel system and tested to insure that they meet current customer needs. Once completed, menu or forms structures will be imaged and replicated on the new Esna Officelinx server. Greetings associated with these apps can be re-recorded or professionally migrated (for a fee) to the new Esna Officelinx server. Voice Messages: Most saved messages fall into 2 categories. The first being personal or family messages and the second being business essential messages. In either event, the reason for saving these messages in the mailbox is typically because the OCTel does not provide an option for exporting the.wav or mp3 file to a remote storage device. Again, Esna can employ (for a fee) an automated tool for migrating messages, names and greetings to the new Esna Officelinx server. However, based again on security and risk issues associated with automation as outlined above, THIS IS HIGHLY DISCOURAGED. The preferred method is to network the OCTel servers to the Esna Officelinx server to enable users to safely and securely forward voice messages into their new Esna Officelinx mailbox. At that time, personal messages can be saved to a removable storage or thumb drive and business messages can remain in email or be stored to a SAN or other corporate storage environment as appropriate. Names and Greetings: Again, this is a service that can be provided by Esna for a fee. www.esna.com 11

APPENDIX Appendix 1: Replication of existing features and functionality QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Does your solution provide a selection of TUIs that can be assigned by user or groups of users (COS)? What if your TUI doesn t exactly emulate my existing experience? Does your system provide me with a way of modifying the TUI myself? Does your solution natively support fax or do I need another server? 12

APPENDIX Appendix 2: Voice Systems and/or PBX Integrations QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Can you support legacy PBX integrations that do not support SIP? Can you support native SIP integrations and for which manufacturers? Can you integrate to multiple PBX manufacturers platforms simultaneously? Can you do this without the need to provide a coordinated dial plan? Can you partition your software to support different PBX sites discretely? 13

APPENDIX Appendix 3: Architecture QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Can you replace our system with a server integrated to our existing or future PBX with a physical footprint just like our existing voicemail solution? Does your solution require proprietary hardware or can it run on our existing server standards with us providing the servers? Can your solution run in our virtual environment on our virtual machines? Can we just purchase your software and software support and buy our own servers under our existing server support contracts? 14

APPENDIX Appendix 4: Resiliency and Scale QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS How many concurrent calls can your solution process on a single server? Is there a way to deploy more than one server to grow your solution and if so, how many and what capacity will that deliver? Are you multiple server configurations deployable in a high availability array? Can servers in High Availability also be geo-redundantly deployed? Will each server have a common data base of ALL systems information (i.e. will it replicate more than just names, greetings and message or will all information including systems and applications programming be mirrored)? Can the additional servers be deployed in an active/active array so that all servers can provide real-time failover in the event of server failure? When a failed server is brought back online, will the high availability architecture automatically repopulate the most current data base without human intervention? If your HA or Redundant architecture employs additional database or synchronization servers beyond the basic voice servers, explain how many and where are these located? 15

APPENDIX Appendix 5: Integration with Business Applications QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Can you solution deliver voicemail inside of premise or cloud based email? Does the solution provide for bi-directional message store and message waiting light synchronization without the need to manually manage message status? Does the solution integrate messaging into other groupware touch points like contacts, calendar and chat? Can the solution reflect on/off hook, calendar and physical user presence? Will the solution allow user to leverage the browser as an access point to PBX or phone system features like click to call? Does the solution provide integration to Social or CRM applications like Salesforce.com or Jive? Does your solution provide for open API s or SDK s for integrating to 3rd party business applications or for writing custom communications scripting? 16

APPENDIX Appendix 6: Client Integrations QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Does your solution integrate voicemail into Google Apps, Microsoft Lync, Cisco Jabber or other manufacturers UC&C Clients? Does the solution provide for a native client for messaging, chat, voice/call control, etc.? Does that client provide deployment options for desktop and mobile devices? Can your client be deployed as a gadget or browser extension without the need to load physical device centric software clients? 17

APPENDIX Appendix 7: Design and Implementation Expertise QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS How much of my data (i.e. messages, names, greeting, autoattendants) can you migrate from my legacy system? If we are not able to migrate some or all of the data to the new solution, do you have a published best practices for insuring user acceptance? Does your solution provide for manufacturers documentation for all PBX or Voice Systems integrations? Does your solution provide for manufacturers documentation for all groupware and/or business applications integrations? Does your solution require any schema changes to be implemented to integrate voice messaging into email? 18

APPENDIX Appendix 8: Supportability QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Does your solution require proprietary hardware and if so, where is your closest part/spares depot and trained technicians Is service provided on an 8-5 or 24x7 basis? If your solution runs on open standards, can I provide my own physical or virtual server/s and utilize my existing server/it support contracts for server maintenance? If your solution runs on open standards, do you offer software only and/or software assurance contracts? Do you provide training for systems administration or systems installation and maintenance and if so, is that training available in classroom or via self-paced computer based training? 19

APPENDIX Appendix 9: Financial QUESTIONS? VENDOR 1 VENDOR 2 VENDOR 3 COMMENTS Can you purchase your solution as a perpetual license with an ongoing soft/hardware support and software assurance model? Can your software be purchased in an OPX model with an annual subscription to include the right to use, software support and assurance? Do you have outsourced models for administration, support and upgrades? Can any part of your solution be purchased as a cloud service or SaaS model? 20

CONTACTING ESNA ESNA TECHNOLOGIES INC. 30 West Beaver Creek Rd., Suite 101 Richmond Hill ON Canada L4B 3K1 Tel. +1 905 707 9700 Fax. +1 905 707 9170 Web. www.esna.com FOR HARDWARE AND SUPPORT Tel. +1 905 707 1234 E-mail techsupp@esna.com FOR DOCUMENTATION REQUEST AND FEEDBACK E-mail documentation@esna.com & Trademarks 1992-2014 by Esna Technologies Inc. All rights reserved.