Voice Migration Strategies: Step-by-Step Guide for Moving to Lync 2013 from Cisco Unified Communications Manager

This is a common topic that I get really excited about because there some great new options with Lync 2013. Whether your going the full hog or only part way, there are steps you can take to get where you want to go. If you haven’t already seen the Lync OIP interoperability page yet CUCM is supported for direct SIP IP-PBX support. See the excerpt from the page below. While there hasn’t been a lot of updates for Lync 2013 yet, early deployments have shown a lot of the same configurations still apply.

Support for various options for the purposes of SIP trunking vary by version so make sure to check the configuration notes based on your version  of CUCM.

Back in 2009 I wrote about a similar topic with OCS R2. There were four significant changes in Lync 2010 that made migrations and interoperability less challenging compared to my original post . They were

1. Media Bypass,

2. Outbound number translation on the mediation server,

3. 1: many Mediation Server to gateways and

4. Mediation Server collocation.

In Lync 2013 the improvements continued. Outlined below are the major new features that make the most challenging environments easier to migrate.

1. Multiple trunks to the same gateway support

2. Inter-trunk routing

3. Calling and called ID manipulation

So what migration or interoperability scenarios does Lync present? Well there are quite a few but for the sake of doing something different I will break them down into steps as a possible way to move forward from the initial interoperability to the final conclusion of removing CUCM from your environment. My example environment is a pretty simple setup but the general ideas that make up the steps can be applied to any sized deployment. Of course not everyone is planning to remove CUCM and there is a step in here where you may choose to stop. 

This isn't a set of hard and fast rules that are meant to be followed in order either. Think of this more as a discrete set of steps that can be used to design a migration that meets your requirements. I just put this order in place as a possible way to add some logic to something that could be otherwise overwhelming to the new voice person.

Step 1 Direct SIP

Pretty straight forward. Direct SIP from Lync to CUCM with media Bypass to the MTP. This is really a starting point for most organizations. Establishing the Lync deployment as a subtending PBX is a good way to get the Lync migration underway. CUCM has the capability to allows a combination of Single Number Reach to a Lync client to ring both the Cisco handset at the same time as well as the Lync client or in the case where the user no longer requires a Cisco handset port the DID to Lync. If you port the DID to Lync CUCM becomes a tandem PBX being used for traffic management rather than endpoint termination.

 

One common comment I often hear is I don’t want to manage two dial plans. Or users don’t want to change their DID. Well there is a couple of ways to make this transition easier without the heartache. This early step really doesn’t require a huge dial plan in Lync. In fact its more than likely you will only have one or two routes in and out of Lync, hardly rocket science.

Once engineers are over the fact that the dial plan isn't a big deal, managing DID’s is probably the next consideration. I wrote an article a while back that takes a lot of the issues faced with provisioning the same DID in both platforms out of the picture. There are a few ways to manage this:

1. The cold hard cut over. Swap in the new system and remove the old. This can be jarring on the end user but certainly a commonly used option.

2. Gradual migration through redirection of inbound DID. So basically you are leaving the Cisco phone on the desk for a while but it will not ring as the primary DID and call routing now points to Lync. Call it the equivalent of a safety blanket for users.

3. An alternate answer is to use SIP URI’s and CUCM’s remote destination profiles to ease user pain while making the transition from the CUCM environment to Lync.So now when an inbound call reaches CUCM for users that still want a hard phone,  Lync will ring at the same time but without the cumbersome confusion of requiring unique DID’s in both systems.

Using a SIP URI to mange inbound traffic to Lync has some clear advantages.

1. It keeps CUCM transition dial plan changes to a minimum. Routing via a SIP URI typically only takes one SIP Route to Lync along with the SIP trunking configuration.

2. The requirement that DID’s in each system have to be unique is no longer relevant. I can be 425-555-5555 in CUCM and in Lync I can be +1425-555-5555 and neither system cares because traffic resolving between the two system is using my SIP URI with remote destination profiles. Only voipnorm@contoso.com is passed making number transitions much easier. The added benefit now is in Lync I have my real DID so when I get comfortable and want to make calls from Lync it has my real DID which is also used for conference authentication.

The final consideration is that of caller and calling ID manipulation. Most PBX’s do not support E.164 and those that do most are not configured in that manner. I would guess that 99% of CUCM deployment in the US today are not using E.164 to do call routing. In OCS days this was a big problem and caller ID manipulation was down at a gateway level. In Lync 2010 this got a little easier but still had some limitations with outbound caller ID. In Lync 2013 this is now fully configurable both for inbound called number and outbound called and calling numbers. Albeit that inbound and outbound are configured in slight different fashions there is now absolutely no reason not to configure Lync with E.164 while maintaining full control of the dial plan in Lync 2013.

STEP 2 Adding direct SIP connectivity to gateways

Seems like another simple step but adding a direct SIP trunk from the gateway to Lync once you have a numbers of users taking advantage of Enterprise Voice can make interoperability a little easier. A user could also use Sim Ring from Lync to ring a Cisco Phone. Call it a substitute to using Cisco’s Single number reach or Remote Destination Profiles feature in CUCM which some see as a complex feature to setup.

This configuration also allows calls from the PSTN direct access to the Lync conferencing service rather than going through CUCM. My theory is the less you have transition through other systems the easier interoperability becomes. In this case you can really start to treat the trunk between CUCM and Lync as a simple tie trunk for interoffice calls rather putting every call through CUCM to get to Lync.

In the case of an ISR shown in the diagram this can be done with dial peers placed into a hunt group. The caveat here is that Lync has to have the highest priority for it to work effectively otherwise the calls will still all be routed via CUCM. If a Call comes into Lync that does not have a user associated to the DID, Lync simply can reject the call. This is the simplest call treatment although Lync can do other things but for the purposes of rerouting back to the gateway using the default logic is the simplest.

If you haven’t already noticed I am trying to avoid any IP-IP GW/CUBE functionality as this will add to your overall cost due to CUBE licensing. Although this feature has its place, interoperability with direct SIP between these platforms no longer requires the use of the CUBE feature.

STEP 3 Trunk to trunk routing in Lync to become the primary call routing platform at Corporate HQ

So now your out of voice pilot mode and audio conferencing is now running on Lync. In a traditional legacy migration moving over trunking meant physically moving cables from one PBX trunk card to another or onto a VoIP gateway system as more companies moved towards VoIP. This is still very true in a lot of cases as the number of companies that still have a traditional legacy PBX is surprisingly  very large. When swapping between VoIP Systems though this is a lot easier from a gateway perspective because its more about changing a route over an IP network rather than having to physically move cables between systems.The real question becomes how do you move routing logic between systems.

So below is our original setup. Pretty simple, few routes that is more than likely used for a POC or audio conferencing. This may be where some companies stop so they can ride out their Cisco investment and utilize Lync Enterprise Voice for remote workers or other end user scenarios that don’t require a IP handset.

But for those that plan a full replacement and add more sites to the mix it more than likely going to start looking like the picture below. Lots of dual connected sites to gateways that may even have connectivity to other legacy PBX’s

This is a natural progression as sites are migrated to Lync. In Lync 2010 this is where you would unplug CUCM. This means that to remove CUCM all services now have to be off of CUCM to enable that decision. Well in Lync 2013 with the new capability to do trunk to trunk routing or inter-trunk routing CUCM can be positioned as a subtending PBX while the remaining services are transferred to Lync (see below). This means you can remove some of the gateway complexity as you make the transition. This is also a great option for legacy PBX migrations, rather than deploying analog gateways the legacy PBX can be used to support analog while you migrate other services to IP.

This also keeps the routing core logic centralized, minimizes supporting two dial plans where you have basically reversed the roles of Lync and CUCM.

Below is high level view of the new inter-trunk routing process for Lync 2013. This makes the process of migrations a lot easier as you move between platforms.

STEP 4 Migrating the Branch

Lots of options, so little bytes to write them on. Below I will talk about what I have actually seen myself and also what's possible. I am not going to go into great depth because there is a lot involved in the configuration and dial plan options. I just want to give a high level view of what's being done and what's possible.

I have seen remote branches completed during varying stages of a migration. From the being the very first sites to leaving all the branches till last. There is no rule in my book on when and where branches are deployed in the migration cycle. One of the first companies I worked with started doing branches first before they did the main user campuses because they had new greenfield sites coming online. So even though I have listed branches as step 4 they really can go anywhere in the migration cycle once you have Lync in place.

1. No Survivable Branch Appliance (SBA) – dual connected WAN site - Cisco or other gateway used for PSTN connectivity. This is a very real option that I have seen used in production in a large company. Typically this is used at smaller branch sites of 5-10 users but I have seen some larger ones with 100 users also have this deployed. FXS ports with Analog phones are used for 911 fall back to a PSTN service in the case where a total WAN outage is experienced. Of course this is not for everyone but its an option that allows the use of existing equipment and keeps maintenance to a minimum.

2. SBA either in a  Cisco router or other Partner qualified gateway – there are literally a bunch of different options here, from putting the SBA on a Cisco gateway module to using an AudioCodes gateway with embedded SBA software and data routing capabilities.

3. Survivable Branch Server with Cisco or other qualified gateway.This could be an option for the large branch but with new DR options for Standard Edition I would suggest that a large branch of more than a 1000 users could be better served with a paired SE deployment. This not only gives local assets for conferencing but makes the larger site highly independent. I will get into the value of SE on another day though as it deserves a post of its own.

STEP 5 Removing CUCM 

The last stage is the most obvious and that is removal of legacy PBX’s. Basically turning off CUCM and removing the configuration to support it. Not sure there is a lot to explain here other than ensuring that all services removed before the plug finally gets pulled.

Even though what I have discussed here is a pretty basic setup voice migrations can be a long and complicated process with larger companies taking years to complete. Moving from one VoIP system to another is a lot easier though than moving between traditional TDM legacy systems which is one thing to be grateful for. If you have never done a migration like this before I hope this has been helpful. 

Comments welcomed.

VoIPNorm