Home » Archive » Migrating from Avaya to Skype for Business – Part 2 – Discovery

Migrating from Avaya to Skype for Business – Part 2 – Discovery

In Part 1 of this series I gave an overview on how to approach these types of projects. If you haven’t read Part 1, you can do here.

As I said previously, the discovery is the most important part of these types of projects. You cannot just turn up and expect to migrate users, that’s going to end in disaster. When I perform the discovery phase I look at the following architectures

  1. Client layer
  2. Network layer
  3. Server layer
  4. Telephony layer
  5. Process layer

The reason I take a complete discovery on these layers is to avoid ignorance and making decisions largely upon nothing more than assumptions and people’s say so.

Client Layer

In this discovery I look at the end user state. My aim is to establish a baseline of what hardware, peripherals and working environment is used within the business. You’ll need to document the standard hardware profiles offered to employee types. You’ll find that the customer has at most 3 hardware options for various business functions. The aim is to determine if the hardware is sufficient, whether there is any legacy hardware out there that no longer meets the company’s current standard offering and most importantly if this legacy hardware poses a problem to deploying Office 2016 for instance e.g. Windows XP devices etc. Now you have the hardware profiles, you want to find out who has got what. This can often be achieved fairly painlessly if the customer has a desktop management solution such as Microsoft System Center Configuration Manager. Using this report you can quickly determine if users need replacement hardware to support the end state which will be Skype for Business.

Next, you’ll want to ask the desktop team for a report that shows the latest Windows Updates, more specifically Office Updates and Driver Updates for each system, together with the compliance percentage. This is important because of three reasons:

  1. If you are delivering training to end users and want to drive adoption, then it is important that they all experience the same features and settings in the Office suite, not just Skype for Business client. If Office updates are not levelled over the entire estate, then some users may experience confusion if they are trained to use a feature that is not present in their Office version.
  2. It is important to ensure that current vendor device drivers are installed and up to date on client machines, not Microsoft compatibility drivers. This will pay dividends towards ensuring the best voice quality experience possible.
  3. Ensuring 1 and 2 are complete will make your troubleshooting lives easier because you can work from a common baseline and not end up troubleshooting and resolving corner case issues with out of date versions. It also helps to reduce trouble ticket submission and provides a consistent level of stability to the end state.

Once the hardware assessment has been completed, you need to focus on peripherals. What does the user use today? Probably most users are going to move from physical phone to soft client which will require a headset. If Skype for Business is already deployed, some users may already have a headset, while others may not.

Now if we pay attention to Microsoft Adoption Success Kit, it tells us that we should drive the headset choice by user persona. However, for 60,000 users that is a monstrous task. What I find works if you’re under pressure is to first obtain a list of business units. The speak to the business unit manager to find out what the majority tasks their employees perform in their roles, whether they are hot desk, flexible workers or static desk / cubicle. You’ll find that in the end there will be around 3 may be 4 different peripheral profiles that will fit everyone’s working style.

Work with your customer to find suitable headsets and peripherals that meet each of these 3 profiles. You’ll want to offer USB and/or Bluetooth connectivity plus mono or binaural versions of the headset. Once decided upload these profiles into the customer’s product catalog so that they can be assigned to each business unit. When end user communications go out announcing migration a link can be provided to say “click here to order your headset”. The user will then view the product catalog and view the devices available to them. They can then choose which version they feel will work best for them. Personally, I prefer binaural headsets, but I know many who prefer mono for instance. Why should someone decide that for me?

Now that the end user is cater for in terms of last mile you’re starting to build a picture of the landscape, but you still have no idea where the users are located physically. If you’re expected to turn up to that user’s desk in the dead of night and remove their Avaya phone for instance, you’re going to need to know where they are. This is where you have to engage with site services and obtain floor plans and business unit locations within a building. A customer is never going to be able to provide you with a list of precise locations for each user, so you have to find a way that can work to achieve identification. Usually migration comms to ask the user to leave a post-it note on their monitor with their name on before they leave work is a simple and low-tech solution to this matter so long as the customer can narrow down the search to a few hundred square feet with floor plans.

This is trickier for common-area phones because they don’t have an owner. You’ll need to work with your customer to find a suitable method of discovering the location of these that yields best results. If all else fails, then there is always a site audit option you could take.

Network Layer

Skype for Business consultants often harp on about “well if the network is not sufficient then how’d you expect Skype to work?”. This is true, but before you enter that conversation with the customer it is best to have your facts ready, right? Otherwise, you’ll be making a lot of noise for no reason and deflecting concentration away from more impacting issues that could be lurking in the background. Some customers will be able to give you detailed information on their network. Ideally what you’re looking for is their edge switch standard, QoS standard, Uplink Standard and WAN standard.

When a customer says it’s OK we have gigabit switches, this may be the case, but there could be a design principle in the network standards that says each port is limited to 100Mbps because the uplink cannot support 1Gbps to desktop beyond data switching locally on the switch back plane. So as part of an effort to provide consistency, some network teams will throttle the access ports. This is useful information, especially when trying to design what modalities can be supported and what the critical mass is for that site in your network bandwidth calculations.

Next, do they support end to end QoS? If so what is currently configured at switch level, and what applications / systems already use them? Is there a reservation on uplinks for different applications such as “we reserve 20% for Citrix VDI” What’s the current consumption of the remaining 25% and how would that effect Skype for Business if X people used Y modality etc.?

Another often missed consideration is Power Over Ethernet if you’re deploying phones. Skype for Business phones and meeting room devices are all Class 3 and 4 PoE devices. If the switches only support Class 1 or 2 then you’re going to need additional power. Whether that is external power supplies for each device, mid-span power units in network racks, or complete switch replacement. You’ll need to identify those early on as resolving them are not going to be quick fixes on the night of migration. One last thing on PoE, even if the switch supports Class 3 or 4, it may not be able to deliver this power over all of its ports at the same time. This is usually a PSU limitation. In all honesty, this scenario hardly ever plays a part because most people will be moving to soft client so PoE consumption naturally reduces. A tip for the Program Managers, have you calculated power savings by reducing PoE consumption? I bet not, but you should, especially when reporting ROI to your superiors!

Also take a detailed look at the WAN topology and bandwidth, again go through the cycles of QoS and consumption and use this data to model your bandwidth planning exercise.

Not to forget wireless. One of Skype for Business’s killer features is the mobility element, so if your users are going to use mobility (laptop portability and mobile) then you’re going to want to ensure that the wireless network can support it at each site. You’ll find that most wireless vendors will publish reference architectures and optimised configuration for Skype for Business and may even offer Software Defined Networking (SDN) capabilities.

The output of this discovery should highlight the good, the manageable and the absolute road blocks that will hinder migration and end state. You can then focus the network team on specific things they need to work on in the remediation phase.

Server Layer

The server layer is assessing the Skype for Business infrastructure. Is it fit for purpose? In this discovery, you should be concentrating on hardware and application configuration. If SfB is deployed on virtual servers, does this meet the recommendations for virtual deployments? If not, what needs to change? Do the servers have the correct resources available to them? What does the topology look like, are there any suboptimal considerations?

When looking at the application element, you’ll want to ensure that the voice configuration is built correctly, dial-plans, normalization rules, voice policies, voice routes, PSTN usages etc for each site that you are migrating. In addition, you’ll need to consider E-911 if sites are within the US States that mandate E-911. Consider Call Admission Control and if that is required following the output from your network discovery, least cost routing and location based routing if needed.

Also consider capacities of features. For instance, delegates in SfB has a limit of 25, but you may have users in Avaya with more than this. Group pickup limits on pools for instance, RGS limits etc. etc. Identify those limitations and then issues will be highlighted a lot easier and quicker when you start to build your migration groups.

Consideration for Exchange UM, is this deployed? How is it deployed and the capacity restraints on it? This will help with defining voicemail retention rather than assignment as what tends to happen is everyone gets UM by default anyway, regardless of the fact they may or may not have an Avaya MM mailbox today.

[Top Tip] Finally, one thing that gets completely over looked here, especially if there is an existing SfB deployment being used. You’ll want to perform CQM and KHI on the environment now before you migrate. This is to protect the project against existing and then compounding issues. You may have assessed configuration to determine that it all looks good on paper, but you won’t know how its performing. I’ve been in situations before where there have been voice quality issues and I was getting beat up over issues that I was being blamed for when in fact they existed before I did anything. So, running CQM and KHI sets the baseline and also highlights potential issues that are just beyond the horizon.

Telephony Layer

This discovery I am going to break into 5 sections:

  1. Avaya Topology
  2. Call Delivery
  3. Station Identity
  4. Station Functionality
  5. Station Complexity

Avaya Topology

You’re obviously going to want to know where the user’s stations are registered to and in which site. You also need to understand how Avaya routes calls in and out of the PSTN to each ACM as well as internal calls that transcend different ACMs in the Avaya network. This discovery from a Skype perspective is nothing more than a Visio diagram with some verbiage around dial patterns and routes etc. But the aim here is not to pick fault at the Avaya deployment as it serves no purpose, but to just understand the layout.

Call Delivery

This discovery is to ascertain how calls are delivered to Avaya and SfB. What the PSTN connectivity is e.g. ISDN, SIP etc. Where those PSTN connections are, because in Avaya world you can have media gateways at branch sites, but the ACM is central in a hub site. How calls are currently delivered to SfB, is this via Avaya, via and SBC or Direct SIP connectivity through SfB SBCs to the PSTN. You’ll need to fully appreciate this because it will form the foundations of your migration approach.

Station Identity

You need to work out how you are going to identify stations that can be migrated. Avaya CMs will typically have multiple users assigned stations from lots of sites, so how can you filter these down to specific stations you need to focus on? Obviously, the uniqueness is going to be the station DDI, but not every station has a DDI. Instead they have extensions. Extensions may not be globally unique so you need to determine how to filter down to a unique extension. Some company’s employ a global dial plan where they’ll take an extension and prefix a global identifier to it e.g. “44”. Then when this is dialled Avaya will know where to route the call internally and find the station. This allows extension 12345 to exist in the London and Seattle offices, although identical, they are globally unique in the GDP. Normally you will use the GDP number as the identifier of stations. Next is how can you identify the station to a particular user? You can’t rely on the station name, so perhaps you’ll need to reference another source such as AD, HR system, Staff Directory etc. Once you’ve got two data points you can then perform matching against the data sets to find out how many stations you can track to a user or business function. What’s left is your remediation action.

Station Functionality

This one is perhaps the most intensive and complex element of this discovery. People just don’t always have simple calling needs. Avaya stations have 100’s of settings and features that just cannot be replicated in the SfB world. So, we have to condense these down into the most valuable features vs what is transferable to SfB. Typically, the following features are migratable:

Avaya Feature Skype for Business
Bridged Appearance Delegates
Coverage Answer Groups Team Call Members
Coverage Paths Call Forwarding No Answer
Non-Skill based Hunt Groups RGS
Pickup Groups Pickup Groups
Remote Call Coverages Simultaneous Ring
Unconditional Call Forward Call Forwarding Immediate
Off-PBX Simultaneous Ring
Team Call Team Call Members

Some Avaya PBX features will map to the same Skype for Business feature e.g. Remote Call Coverage and Off-PBX both map to SfB Simultaneous Ring. Obviously, you can only have 1 Sim Ring destination, so a design decision needs to be made to determine order of precedence. If that is RCC and both RCC and Off-PBX are configured on a station then RCC is migrated to Sim Ring for instance.

Like I said not all station functionality can be replicated, and yes, the end user will be disrupted. However, through proper training, awareness and adoption strategies these can be mitigated.

Station Complexity

Stations themselves are straightforward to identify. However, what is super complicated is figuring out their complexity and ties to other stations. You’ll have stations with multiple bridged appearances, team call button, hunt group and group pickup membership. It is often normal to find stations with at least 10-15 ties between other stations and these can incept into other stations not directly related to the primary station you’re looking at. For instance, station X could have a bridged appearance of station Y this would mean the both these stations would need to migrate at once to keep the tie intact. However station Y could be in a pickup group with Station A, B and C. This means that stations X, Y, A, B and C need to now migrate in the same group as each other.

The big question is how do you identify such complexity and group ties?

You could do this manually by interrogating Avaya but I’d rather slit my own wrists than do that. You could approach the migration from a clean perspective and leave it to the end users to create their own delegates / team call members etc. and manage that through training and communication, or you could use a 3rd party solution that specialises in discovering these ties and perform automatic grouping analysis.

Process Layer

Lastly you must discover the processes in place at the customer around provisioning and de-provisioning of telephony users because at some point, they will need to change their process to provision on SfB by default. You will need to articulate where in the process the steps need to change and what needs to happen so that their MACD process does not interfere with your migration commitments. The last thing you want to do is migrate 1,000 users out of a site and be packing up your camping gear only to find that there are 50 new users you didn’t know about. Large organizations will have automated processes that use syncs between HR systems, AD, and other internal databases which can be mind-blowingly complex, so you really need to understand how all that works before you start writing information to a user’s contact card information for instance.

Also, a topic that is going to come up will be DDI Management. How are phone numbers tracked and managed across systems? This topic is way too varied to blog because everyone has their own unique take on DDI management, but be sure to be ready to tackle that issue.

In Part 3 I will discuss how to use Unimax 2nd Nature with Migration Pro to help you unpick the telephony discovery and highlight remediations that need to take place before your proof of concept. Stay tuned


Leave a Reply to julianthefrank Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: