Communications and Collaboration

Planning Your Migration to Unified Messaging

Jeff Goodwin

At a Glance:

• A brief history of voicemail
• Things to consider when planning your migration
• Migration strategies
• Multi-site challenges

Contents

A Brief History of Voicemail
Planning Your Migration
Practical Migration Strategies
A Migration Walkthrough
The Importance of Following a Plan

Migrating from a legacy voicemail system to a unified messaging platform can be a challenging project. But with some proper planning, you can accomplish this migration quite easily while minimizing any disruption that end users may experience. In fact, minimizing the

service disruption should probably be your primary goal when running a migration project of this sort.

To know what you need to plan for during your migration, you must first understand why companies feel voicemail is a mission- critical application. This basic information will help you understand what features you need to implement when migrating to Unified Messaging and why those features will be important to administrators.

A Brief History of Voicemail

Since you can't really plan how to get to your destination without knowing where your journey will begin, I want to step back and give a quick overview of voicemail systems—both where they come from and how they are architected. There are arguments about who invented the first voicemail system. However, the first commercially available voicemail system was called VMX, which stood for Voice Message Exchange.

VMX was originally designed to provide a way to communicate by voice to other people within the company, just as e-mail is used today. The system had such commands as send a message, forward a message, and reply to a message. When a message was left, the user was notified. There were various notification methods, including out-calling (ringing the person on a specific phone number) and a message-waiting light (an indicator light on the person's phone).

As VMX continued to gain popularity, organizations began to network their voicemail systems together. This offered an enterprise- wide voicemail solution where employees could send broadcast messages to company- wide distribution lists.

Of course, to provide a way to interact with the voicemail system, a touch-tone user interface (TUI) had to be created. These TUIs have varied over the years, and, unfortunately, there is no standard interface for voicemail. If you have voicemail on your cell phone, you're probably used to hearing something like "press 1 for voicemail." But as speech-driven voicemail systems, which use voice user interfaces (VUIs), become more common, the TUI itself isn't as important as it used to be. However, you shouldn't underestimate the attachment that users may have to a specific interface.

Enterprise voicemail systems in use today rely on two distinct architectures: distributed and centralized. In Figure 1, the Seattle, New York, and Austin offices have a distributed voicemail architecture, where the voicemail systems are co-located at each of these sites. In contrast, the London, Paris, and Glasgow offices have a centralized model, where the PBX infrastructure is networked together and all calls are routed back to the central location in London. Both models have advantages and disadvantages. But note that even in a distributed model, the voicemail systems can be networked together for message delivery between sites.

Figure 1 The two common voicemail architecture models (Click the image for a larger view)

There are three primary reasons for why an organization may choose to use a distributed model: a need for local availability, the use of disparate PBX systems that can't be networked together, and uniform dial plan restrictions.

Some organizations require the voicemail system so that in the event of a network outage, the local PBX and voicemail system will still operate normally, giving the site full system functionality. Interactive Voice Response (IVR) systems will still work, and outside callers can still leave messages. In effect, there is no impact on end users, and work continues as normal. This may sound familiar—this is the same reason many organizations choose to localize their servers running Microsoft® Exchange Server. Your organization may want to perform a risk assessment to determine whether this localized survivability is necessary.

When an organization grows by acquisitions, the remote sites will often have PBX platforms that cannot be networked with the rest of the infrastructure. In this case, organizations can either change out the PBX, which can be a costly project, or leave the site intact and network the voicemail platform to provide a seamless voice messaging exchange. Third-party servers are also available to help you network your disparate voicemail systems.

In order to network PBXs together, a uniform dial plan (or UDP) is required. A UDP says that phone and voicemail extensions cannot overlap. In Figure 1, you'll notice that Seattle, New York, and Austin have overlapping extension ranges. This is because there is no UDP for the sites located in the United States. A UDP could be created by extending the extension ranges to 7 or 10 digits, but this creates other issues.

You may have to change the dialing templates on each phone, change all user extensions on the PBX, and change any applications that integrate with the system. And this can cause user frustration for employees who now must remember and dial 7- or 10-digit numbers to call someone down the hall.

While these basic features and architectural challenges have been improved over the years, the basics of voicemail remain the same. Message exchange, networking, notification methods, user interface, and architecture all are important factors that you must keep in mind when you plan a migration.

Planning Your Migration

Unified Messaging brings changes to every part of the organization—from how users interact with voicemail to how architecture is designed to how administrators handle management. All these differences must be addressed when you migrate to a unified messaging system. What follows is a checklist of things you need to take into account when planning your migration.

Message Networking Any organization that transitions from a legacy voicemail platform to Exchange Unified Messaging must have a period of coexistence. If your organization has already deployed message networking, which is a system to interoperate different voicemail systems, simply add the Unified Messaging system to the list of existing systems. I strongly recommend message networking for any organization that has multiple locations with separate voicemail or PBX systems.

Infrastructure Designing the infrastructure for Unified Messaging will require you to make decisions on networking requirements, telephony integration, server placement, and the like. If you are not already familiar with basic deployment strategies, read my previous article "Deploying Unified Messaging with Exchange Server 2007" (see technet.microsoft.com/magazine/cc137737).

Automated Attendants Many systems contain multiple automated attendants—different ones for, say, daytime, nighttime, and various departments. You'll need to work with your organization's telecom team to mirror the automated attendants on the legacy voicemail systems.

Message Waiting Indication You might wish your solution could do without message waiting indicators, but your users will probably demand this feature. So don't underestimate how attached users are to that red light notification. Fortunately, there are several companies that have developed message indicator applications for Exchange Server.

Fax Support Many legacy voicemail platforms support inbound faxing. Exchange Unified Messaging also supports inbound faxing capabilities, so you may want to plan on supporting this in your new deployment.

Interactive Voice Response Some legacy voicemail platforms support Interactive Voice Response (IVR) applications that Exchange Unified Messaging can't duplicate. You may want to leave these systems in place until a suitable alternative can be found.

Administration Exchange Unified Messaging relies on Active Directory® and the Exchange Mailbox Server role. You will need to plan for how administration, system requirements, and the like will be affected by a Unified Messaging deployment.

User Interface When rolling out a new UI, you must provide training for your users. Exchange Unified Messaging employs an interface that is very similar to most cell phone providers, so it should be fairly intuitive for most users. It also uses speech recognition so that users don't need to use touch tones. In Exchange Server, this is referred to as Outlook® Voice Access.

Training Unified Messaging brings a paradigm shift in the way your users communicate and use voicemail. Beyond the UI, you must provide training to your users to teach best practices and present the new, more efficient ways they'll be able to communicate. For example, users may not know how to interact with voicemail in their e-mail inbox or how to configure some advanced unified messaging settings.

Practical Migration Strategies

There are challenges, no doubt, in migrating a large organization to a unified messaging solution. However, I have been working in unified communications for 10 years and have seen even the most complex of organizations with very specific requirements successfully migrated.

Whether you're dealing with a single- or a multi-site organization, it will help if you build your migration strategy around these five basic steps:

1. Plan and design your solution.
2. Install and configure the Unified Messaging Server role.
3. Migrate a pilot group.
4. Revise your design based on feedback from the pilot group.
5. Migrate your users.

Of course, multi-site organizations do face certain challenges that are generally not found in single-site scenarios. I discuss those challenges separately in the "Multi-Site Challenges" sidebar.

Planning and designing your solution is the single most important step in the migration process. I recommend you assign a Unified Messaging team to the project. This team should include representatives from various parts of your organization with expertise in telecom, Active Directory, Exchange, networking, security, training, and project management. And get a detailed architectural drawing of your company's existing PBX, voicemail, and e-mail infrastructures.

Once you have a design, you can install and configure the Unified Messaging Server role. Don't be afraid to install a United Messaging server in parallel to your existing legacy voicemail system. Just be sure you follow the documented best practices.

At this point, you're ready to try out your Unified Messaging server. Designate and migrate a small pilot group of users to the new system. A group of between 25 and 50 users will do. Choose these users carefully, creating a pilot group that consists of a varied group of users, from IT and telecom staff to departmental managers and sales personnel. By involving such a wide range of people, you can better determine whether your design is on target, what specific requirements you need to take into account, what training may be necessary for users, and so on.

After you receive feedback from the pilot group, you'll need to revise your design to address any issues that have been uncovered in testing. More specifically, revisit the items I discussed in the "Things to Consider" section and make sure you've addressed those points appropriately for your organization. Note that the most common changes made here usually pertain to training.

The final step is to migrate your users. There are many opinions and strategies regarding how to migrate the system into full production. The two primary methodologies are a gradual migration and a flash-cut.

If you choose to gradually migrate your user community over a period of weeks or months, you will create voicemail islands between your legacy and Unified Messaging users. This prevents users from forwarding messages to one another via voicemail. And if your design doesn't include a message networking solution, you will disrupt some of your business communications. If you are going to do this, I recommend you be sure to include a message networking solution in your initial design.

For a flash-cut migration, you move all your users in a single phase. Organizations typically perform this sort of migration over a weekend so they have time to test the system, make configuration changes, and back out of the migration in case a serious blocker is encountered.

Whichever method you choose, be sure to train your help desk personnel on the common questions and answers you gathered from your pilot group. You should also make sure the help desk workers are proficient at performing key tasks, including enabling a user, validating that a user is enabled, and changing a password.

A Migration Walkthrough

As I go through my sample migration, keep in mind that the primary goal for a successful migration to Unified Messaging is to move the user's voicemail box from a legacy voicemail platform to Unified Messaging with as little disruption to users (both internal and external) as possible.

Figure 2 details an organization's architecture. It has no plans to change this mixed Exchange architecture. The U.S.-based offices have a primary datacenter located in Seattle. All IT applications for Austin are served from Seattle, and the New York office warrants localized Exchange services. Voicemail for the U.S. locations are distributed due to the disparate PBX infrastructure. Technically, the PBX infrastructure cannot be networked to provide centralized voicemail. The European offices, in contrast, have a centralized datacenter located in London. All the IT and telecom applications in Europe are served from that central datacenter.

Figure 2 Sample architecture before migration (Click the image for a larger view)

The entire voicemail infrastructure is based on the Octel (now known as Avaya) platform. All voicemail systems have been networked together using Octel Analog Networking (OAN), which is a proprietary networking protocol that uses analog phone lines and long distance calling to send networked voicemail messages. This architecture allows for corporate-wide voice messaging between sites.

Multi-Site Challenges

Multi-site organizations are faced with any number of challenges when deploying Unified Messaging. Fortunately, you can learn from some of the challenges other organizations have already faced. I can't cover every challenge in this article, but I can tell you about the most common challenges I have encountered when working with various organizations.

"I have a centralized Exchange Server architecture and a mixed telephony environment."

A distributed environment is easy to design. You place a Unified Messaging server and integrate it with the local PBX at each site. But what if you have a centralized or even a mixed environment? The question you need to ask yourself is whether you require local Unified Messaging survivability at the site. With local Unified Messaging survivability, that location can lose its connection to the centralized Exchange server and still provide automated attendant functionality and allow outside callers (quite possibly customers) to leave messages. The answer will likely depend on how mission critical that location is and how manageable the solution will be.

If you require local survivability for your site, a remote Unified Messaging server at the site might be a good option. If it is not a requirement, you can install an SIP Gateway at the local site. Exchange Unified Messaging has the flexibility of not requiring you to network the PBX infrastructure together, and there is no requirement for a Uniform Dialing Plan.

"I am in the process of upgrading my Exchange architecture."

Many customers are hesitant to begin a Unified Messaging migration while they are in the process of upgrading their Exchange infrastructure. My advice is that if you've already made the decision to move to Unified Messaging, go ahead and migrate while the Exchange server is being upgraded. Simply follow your upgrade plans and there shouldn't be substantial complexity added to the project.

"I have a lot of small sites with fewer than 10 people and some of those sites don't have a PBX."

At smaller sites that have a PBX located on-site, all you have to do is simply install an SIP Gateway at the local site. For sites that do not have a PBX on-site, there are telephony techniques that can be used to forward the phones to the central PBX for call routing to the Unified Messaging system. In short, you can deploy Unified Messaging services to the smaller remote sites in your organization quite inexpensively.

It is important to note that these smaller sites actually provide a great test bed for your migration. One common migration strategy is to start at the edge of the network and then move to the core. You migrate the smaller sites first and then perform a postmortem with the Unified Messaging team in order to figure out what went well and what challenges were encountered. You can then implement those lessons learned when migrating the next site.

The Unified Messaging team has decided to migrate from the edge of the network to the core. For all locations, placement of the Unified Messaging server will follow the best practice of following the Exchange server architecture. The team builds its own planning documentation for each site, keeping in mind the items discussed in the "Things to Consider" section. The documentation is used during installation and configuration of the servers, during user training, and when planning migration strategies.

For each site, the team plans on flash-cutting users to the Unified Messaging system and leaving the legacy platform in place to support IVR applications that will remain in use until an alternative solution can be found. The team decided to wait for 30 days after migration before moving on to the next location. The wait period is meant to ensure that each site has adjusted to the new platform before moving more users and adding more help desk support calls.

The organization decides to migrate the Austin location first. Since the Austin e-mail is served from Seattle, the team installs the Unified Messaging Server role in Seattle and provides PBX integration by installing an SIP Gateway in Austin. And since the legacy voicemail platform is networked together, the team must address the need for networking the Unified Messaging platform by installing a Message Networking server. The users are trained on the new system and the migration goes smoothly, so the team decides to migrate New York next.

The New York location has its own Mailbox and Hub Transport servers. The best practices, therefore, say that a Unified Messaging server should be installed in New York. The team installs the server, following the migration planning documents. The server is added to the list of nodes in the Message Networking server to be included in the voicemail network. The users are trained and smoothly migrated to Unified Messaging.

The Seattle location already has a Unified Messaging server deployed from the Austin migration phase. The team determines that the server contains enough voicemail ports to support both the Seattle and Austin locations. The users in Seattle are trained and migrated to Unified Messaging.

The architecture in Europe is much easier to design. The PBX infrastructure is networked together and Exchange is centralized. A Unified Messaging server is deployed in London and each site is migrated, starting with the smallest site first. Figure 3 illustrates the final architecture.

Figure 3 Sample architecture after migration (Click the image for a larger view)

The Importance of Following a Plan

I have been asked to resolve many failed Unified Messaging migrations. Many of these organizations had broken one or more of the key rules.

First, always remember that it's not just a voicemail system. This is a mission-critical application and should be treated like one. Users rely on voicemail technologies for exchanging information. Keep in mind that this is a business application and plan your migration to account for all the considerations I've discussed in this article.

You absolutely must involve the telecommunications team in any migration to Unified Messaging. The telecom team will have the best understanding of the telephony applications that are integrated into the corporate infrastructure.

When migrating to Unified Messaging, plan for the enterprise solution. While you may just be implementing a single site in the beginning, you should always have the big picture in mind. For example, implementing a single site without providing Message Networking to your other sites will impact communications between users. This, of course, can be a big task, so don't be afraid to consult a specialist to design an architecture that takes into account all your IT applications.

Finally, don't underestimate the importance of training. Unified Messaging brings a paradigm shift in the way users communicate and interact with voicemail. What seems intuitive to you, may not be as intuitive to others. Good training is key to creating the smoothest transition possible.

Jeff Goodwin is a Senior Technologist at The VIA Group, specializing in Exchange and Unified Messaging design and deployment. You can reach him at jgoodwin@theviagroup.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.