Home » 2018 » March

Monthly Archives: March 2018

Migrating from Avaya to Skype for Business – Part 5 – Migrating with MigrationPro

In Part 4 I discussed how Unimax MigrationPro Grouping component to analyse station ties and grouping them together into migration groups.. In this post I will be focussing on the actual migration process.

Before I jump into the application, I wanted to spend a little time discussing the migration build up. Migrations are not as simple as just assigning a number and away you go. Generally, migrations fall into 2 fundamental concepts:

  1. Migration retaining DDI
  2. Migration with new DDI

Migrating when retaining a user’s DDI is far more complex than migrating and assigning a new DDI and running essentially two complete phone scenarios side by side. For the purpose of this blog series I am going to focus on the more difficult concept as you can use the same methodologies to implement the simpler approach.

When migrating a user and retaining their DID, you have to complete quite a substantial piece of technical work in order to do this. This is especially true if you’re migrating from a QSIG to SIP platform. You will have heard many times from various sessions and blog posts over the years the concept of SBC placement being upstream or downstream. Without going into too much detail on the best placement and the logistics involved in that project, the safest bet is to place the SBC upstream to your QSIG PBX so that post migration, you can remove it. There may be other workstreams running in parallel which could be to migrated QSIG to SIP, and if this is possible then the deployment model is a bit less disruptive because you don’t have to arrange downtime to switch your QSIG links from legacy PBX gateways to your brand new SBC.

Essentially though whether you’re staying on QSIG or moving to SIP, coexistence between legacy Avaya and SfB is mandatory for this type of migration. At a very high level you’re going to want to achieve the following:

  • Avaya to Skype internal extension dialling and vice versa
  • Inbound PSTN call delivery to destination based on user registration

To complete the internal extension dialling you’re going to need a dial plan on SfB and Avaya that is able to route calls via the SBC based on extension numbers. Normalization should be configured so that the same extension range can be used on both systems, but reverse number lookup doesn’t prevent dial out of a source system if no local number route has been found.

To complete inbound PSTN delivery, you’re going to need some logic at the SBC level that can make a decision on where the called number is active i.e. on Avaya or Skype. This is usually performed using AD routing where the SBC queries AD for a specific attribute that is populated that defines whether the called number is on Skype or not. This can be a native (e.g. use msRTCSIP-Line) or custom attribute depending on your circumstances.

Let’s assume for this post that the above has been configured and coexistence implemented.

Now we need to evaluate the technical procedure required to migrate an endpoint from Avaya to SfB. Typical migrations will look like this:

  1. Enable the user for SfB Enterprise Voice
  2. Assign the user their Line URI including extension number
  3. Assign the user a site dial plan
  4. Assign the user a user voice policy
  5. Configure the user’s call forwarding settings
  6. Configure the users boss / admin and team call settings
  7. Add user to Group Pickups, Hunt Groups, Shared Line Appearances etc.
  8. Enable the user for Exchange UM
  9. Update Avaya to redirect internal calls originating from Avaya to SfB

Step 5 through 7 will be dependent on whether the user requires the configuration, but the rest are mandatory for any user.

Now you know the high level process you need to follow, you have to decide whether you can pre-build most of the process in advance, or whether you have to execute this all on the migration evening. That decision is largely down to what the business will accept. What I typically try to steer is that steps 1, 2, 5-7 are executed ahead of migration in a pre-migration task. This allows me to create the most complex scenarios ahead of time without major impact to the user who may be using SfB for IM and Meetings for instance. It means that on migration night I only have to perform steps 3, 4,8 and 9 regardless of a user’s phone complexity which allows me to migrate more users per night and achieve a higher success rate. It also means that the process is repeatable and can be completed by less technical resources.

However, this is sometimes not always possible, and you end up migrating all steps on the migration evening. That’s fine, it just means the concurrent numbers per evening will be less and the migration phase elongated.

Step 9, how you do this will be unique to your Avaya configuration, but the easiest and cleanest way is to update the Uniform Dial Plan on the Avaya CM to redirect calls to the migrated extension to Skype. This works by inputting a string i.e. the extension, then prefixing a code that will then use Automatic Alternate Routing to route the call over the Avaya to SfB SIP trunk.

e.g. Dialled string = 12345 => Prefix = 39 => AAR Selection = Auto. In AAR you’ll have a rule that says any number starting with 39 and is 7 digits long route over trunk 9 or whatever the trunk to SfB is.

Once the technical challenges have been overcome you may need to consider environmental scenarios, logistics, procurement and any other decision gates you have to pass through before a migration can be executed.

An important element which I will touch on is roll back. What if a migration fails, what is your roll back strategy? My advice is that you’ll want to leave the Avaya configuration alone for the station. Don’t remove it or change it, you don’t need to if you’re using UDP. This means that rollback is as simple as undoing the changes in SfB, and removing the UDP entry and everyone is happy. As soon as you delete or change stuff to the station configuration in Avaya, you complicate roll back and that will give you more pain, especially if you do not know the original state.

Assuming the worst case and you have to complete all migration steps in the same evening, then you can use Unimax MigratioPro Migrator to complete these technical tasks for you.

Before you can run the migrator, grouping must be completed. When you target a specific migration group e.g. Group 1000 you need to consider that groups custom SfB needs, i.e. which dial plan, what does their line uri format need to be, what voice policy is required, do I need to update anything in AD? Do I need to do anything in Avaya beyond the UDP entry?

Once you have these parameters you’ll want to modify MigrationPro configuration file.

Like Grouping, you’ll need to add in all the systems involved in the migration of the users. In the <appSettings> config block add in the systems

If the user is not enabled for SfB, you’ll want to add in the default enablement settings into the <userCreate> config block within the <skypeForBusiness> element like so:

Now when migrating enter the settings you need to update in SfB for Migration into the <userUpdate> config block

Next add in the Exchange UM settings needed to enable voicemail in the <mailboxUpdate> config block

Lastly enter the Avaya UDP entry into the <udpCreate> config block

If you need to modify AD attributes, there is a section in the configuration file for that too.

Now I am going to migrate group 1000 from this list to SfB

In Command Prompt I will browse to the migrator directory

Now I will run the migrator using the following command AvayaCMToSfB.exe –group 1000

Wait for the migration to complete

Now in 2nd Nature we can see that the SfB Line URI meets E164 standards, sim ring has been configured and a migration date entered

And if we focus in on a user we can see that their SfB EV settings have been updated and their Exchange UM Mailbox created

While MigrationPro focusses on user station migrations we also need to consider Common Area, Meeting Rooms and Office Shared Numbers.

Shared Numbers will need to be migrated manually. But the best way to migrate CAPs and Meeting Rooms is to create new accounts in SfB with a new extension range and just replace and leave the old configuration in place. There is very rarely a need to waste time migrating these because they only require outbound calling, not inbound. So they never need to keep the same identity from an extension perspective.

This completes the blog series, I hope you found this useful when executing your own.

Migrating from Avaya to Skype for Business – Part 4 – Group Using MigrationPro

In Part 3 of this series I talked about how you can leverage Unimax 2nd Nature to discover your Avaya estate, how it matches users from AD to Avaya and SfB etc. In this part I am going to be focusing on post discovery tasks that need to happen before migrations can begin.

When migrating users, the reality of the world is that they will expect a level of configuration to migrate with them. Simply enabling them on SfB and telling them to go ahead and recreate their boss/admin or team call group etc in large complex organisations just doesn’t work. Take it from me who has seen the feedback survey results after migrating in this way, it doesn’t go down too well, even with the best adoption strategy.

This makes our lives as migration engineers harder because now we have to micro cater for each individual. In Part 2 I listed the features that can be migrated from Avaya to SfB with little hassle, as long as you know the source settings. Many users will have lots of dependencies on other stations in Avaya, bridged appearances, off-pbx, remote call coverages, coverage paths, coverage answer groups, call pickup groups, hunt groups etc. All of these can of course be migrated, but you’ve got to sit down and figure out the dependencies these features have on other stations within the business.

Now there are several ways to do this, if you’re a coder, you could probably use Avaya APIs to suck config into a SQL database and then build relationships and produce a report, you could suck out the data into Excel and work your excel foo, or you could just get a third party software application to do it for you. I prefer the latter!

So continuing the theme of using Unimax’s solutions to help, I will now focus on MigrationPro. MigrationPro is an additional application that leverages 2nd Nature. Therefore, you cannot buy MigrationPro without 2nd Nature. MigrationPro uses the web services 2nd Nature API to perform actions on the 2nd Nature database with a view of pushing out changes to connected systems.

MigrationPro comes in two elements:

  1. Grouping
  2. Migration

In this post, I am going to focus purely on the grouping element of MigrationPro.

In order to use MigrationPro you need to ensure that your AD, Avaya and SfB configuration is accurate. It will only work on users who have been matched to an Avaya station correctly. It will not group / consider stations that cannot be matched to a user. This is important, so if you’re thinking this application is some secret sauce to your remediation woes, then think again!

When grouping MigrationPro considers the following Avaya to SfB feature map:

Avaya Skype for Business
Extension Line URI Extension
Modular Messaging non-dormant mailbox Forward No Answer Voicemail
Unconditional Call Fwd Internal Forward Immediate SIP Address
Unconditional Call Fwd External Forward Immediate Number
Remote Call Coverage (external) Simultaneous Ring, Forward No Answer Voicemail
Remote Call Coverage (internal destination) Simultaneous to internal number of Skype for Business User
Station Off-PBX Numbers Simultaneous ring to first off-PBX number
Coverage Answer Group Membership (All phones ring at the same time) Team Call Members added, Simultaneous ring to team call group
Bridged Appearance Station Buttons Delegate added, Simultaneous ring to delegates
Pickup Group Membership Call Pickup Group Members added using the first nonempty pickup group number
Hunt Group Membership Hunt Group Membership

The actual grouping and station relations are calculated using the following Avaya features:

  • Stations
  • Bridged Appearance
  • Coverage Answer Groups
  • Coverage Paths
  • Non-skill based Hunt Groups
  • Remote Call Coverage
  • Vector Directory Numbers
  • Unconditional Call Forward

When setting up a grouping task, you must add in all the systems you want to consider for grouping. This is done in the Grouping config file located in C:\Program Files\Unimax\MigrationPro\Avaya\Grouping. Under <appSettings> config block add in the system IDs you want to consider e.g. AD and Avaya CM

Next there are different ways in which you can target AD users, by Security Group or OU. It depends on how you’re planning on conducting the migration, but more than likely, you’ll just want to add the base user AD OU into <includeOUs> config block.

Now you may want to restrict users eligible for migration. Perhaps you just want to focus on a site, or department. In the <includeAttributes> config block you can add a filter on an AD attribute e.g. Office Location

Now on the Avaya system we will want to exclude some station types from grouping such as Analog, Fax, Modem, VMBox etc. This is done in the <excludeStationTypes> config block

You can skip stations by extension number too if you need to. Once this configuration file is ready, save it and then you can run the grouping program.

For the purpose of this post I have configured my configuration file to target these stations for grouping in 2N

Take notice to the columns Migration Group, Complexity and Group Ties. MigrationPro will write to these 2nd Nature fields

Open Command Prompt and change your working directory to the grouping folder in MigrationPro

Run the AvayaCMGrouping executable

Grouping will now take place. This process could take several minutes or hours depending on the amount of records involved

Now you’ll notice in 2nd Nature the fields I highlighted before have been populated

Migration Group now has a number. This means that any station with the same group number must be migrated at the same time. The Group ties column is what is tying the stations together, so extension 59000 has Bridged Appearance to extension 59001, in Call Pickup Group 4 with extensions 59007 and in a coverage path with extensions 59007 and 59008. The complexity column is the number of ties the station has to other stations. This number begins at 10, so extension 59000 has a complexity of 13 because it has 3 ties to other stations.

Stations with Migration Group ANY, are simple stations with no dependencies and can be migrated at any time to suit the end user.

Once run, you can now use this report to extract into your migration schedule and begin planning your migration.

In Part 5 I am going to talk about the Migration Approach and how that plays a part in using MigrationPro Migration element.

Migrating from Avaya to Skype for Business – Part 3 – Unimax 2nd Nature

In Part 2 I talked about how to architect a discovery and the reasons why each element is required. In this post I am going to be zeroing in on the telephony feature and dependency discovery.

There is no two ways about it, the migration of users or extensions from Avaya or any other VoIP or PBX solution to Skype for Business is the most difficult phase of the overall Microsoft UC deployment project. Users and the business will expect some form of service continuity while expecting change. By this I mean some features we can forget about migrating because they just don’t exist in SfB or SfB’s behaviour just doesn’t require them and the business will accept these after due diligence. However, there are some basic and most relied upon features that must to migrate in order for the business to operate. These are usually broken down into two categories:

  1. User features
  2. Business Services

User features are things that one or more inter-linked users depend on in order to serve their customers and maintain the level of coverage they require. These will typically be features such as:

  • Bridged Appearance
  • Team Call
  • Coverage Path
  • Coverage Answer Groups
  • Group Pickup
  • Remote Call Coverage

These tend to be the most common and heavily relied on features that I come across in most businesses. These features are of course migratable (see part 2 for Avaya to SfB feature map).

Business services are front of house or internal service numbers that may have an advanced call workflow configured, or simply provide coverage to a business service (e.g. security office). These can be migrated to SfB, but caution and consideration must be taken to ensure that from a feature set perspective, SfB can recreate or at least re-design the solution to accommodate the workflow, especially from a RGS perspective at least.

Business services are usually easy to solve in the grand scheme of things. More often than not these are validated and rearchitected by using a business engagement strategy to interview the stakeholders and collectively come to a design that is mutually acceptable. User features on the other hand, they can get very very very complex.

Obviously approaching every user and interviewing them on what feature they use is impractical. There is also the fact that they may have a button feature configured from 2005 which they no longer use. This is impossible to remediate out programmatically as CDRs for feature buttons just don’t exist. Anyway, back to the point. A user may have dependencies on other users. Those users may also have dependencies on yet other users and so on. Out of the 9 or so features you can migrate there are 9^9 possible combinations of user dependencies, or 3,87,420,489 (I’m not even sure the commas are right). Truly an astronomical number by any means.

However, don’t panic it never works out to be that complex. You’ll find that most users will have dependencies on between 5 and 15 others as a general average. So, you can stop reaching for your kitchen knife right now, there is light, come back to the light!

So how do you discover these dependencies? If you’re anything like me, I don’t have a wealth of Avaya knowledge, I know enough in order to articulate what I need to in order to migrate, but sit me in front of a CLI and I’d be like er, yeah, can you call me a cab? This is a real challenge in the industry though. Most people come from Microsoft backgrounds in SfB and voice and UC is somewhat of a swamp full of alligators waiting to snap at your heels. Customers expect you to know both the source system and SfB and that is unrealistic, and only a few people in the world will actually have detailed knowledge of both environments in order to complete end to end activities. Luckily there is a tool that starts in a long way to make your lives easier and help you understand only what you need to in order to complete your migration. Recently added to SfB IT Pro Tools, Unimax 2nd Nature MACD application can cut out months of hard labour and frustration making migrations a lot simpler.

I may do some in depth blogs around how 2nd Nature (2N) is architected and how it connects to systems etc. But for the purpose of this blog series I am going to assume that all the setup etc is complete. I will start by saying though that 2N is basically a MACD platform that can add, move, remove and change configuration records on multiple UC / VoIP / PBX solutions at the same time and in a sequence. The ability to perform MACD in an admin defined sequence is what gives it the ability to be used as a migration tool as well.

The most important thing to realize about 2N before you start is that it uses a system hierarchy in order to move / add users across systems. In other words when we are talking about user direct extensions, then the configuration must relate from Parent to Child systems. 2N uses Active Directory as its parent system. All other systems are located logically underneath the AD System. This allows 2N to look at a user in AD and automatically see their configuration across, Avaya, SfB, Exchange UM, AD and Avaya Messaging, giving a complete picture of their old and new world state.

Before you can begin to discover user’s who can migrate to SfB and before you attempt to discover the user’s inter-extension features, you must perform a discovery and remediation exercise to make sure that Avaya extensions can be matched to an AD record. Otherwise, you’re just going to be looking at a bunch of stations with no clue who they belong to. Obviously not all stations will match to an AD user e.g static office phones, common-area, meeting room etc. But these are handled differently anyway.

In order to match an Avaya extension to an AD user, 2N uses a primary key on the AD telephone number. This can be any field, not specifically telephone, but the AD field must contain the Avaya extension as found in Avaya in order to create a matched record. You set this here in the AD system parameters

Now most global businesses will have more than one Avaya CM and have extensions that will be the same in different regions but logically unique. So 2N needs a way to determine how to find a globally unique extension. What can be done is you add a custom field to 2N that you’re going to use to create a globally unique number. If a customer has a global dial plan, then you can use this method, but if not, you can create one in 2N that works inside 2N only. The scenario goes like this:

Avaya CM in London, extension range 6000-7000 & Avaya CM Boston, extension range 6000-9000. So, without doing anything, we wouldn’t be able to match a user to a unique Avaya extension because the extension ranges overlap in Boston and London. If we added another field e.g. Extension 7-digits. Now we can use transformation rules in 2N to transform the 5 digit extension into a 7 digit global unique extension into field Extension 7-digits based on the source system e.g. NYC or London Avaya.

Example:

Any extensions from Boston Avaya CM transform 6XXXX to 106XXXX, 7XXXX to 107XXXX, 8XXXX to 107XXXX, 9XXXX to 107XXXX

Any extensions from London Avaya CM transform 6XXXX to 446XXXX, 7XXXX to 447XXXX

Now that we have a unique field in Avaya, we need to do the same for Active Directory. First you need to find an AD attribute (e.g. telephoneNumber) that contains the DDI if there are no attributes that already match a GDP pattern. Once you have got the DDI you need to understand where the DDI ranges relate to an Avaya CM. For instance, in London the DDI range could be this 01782786000-01782787000. Once we have that we can now add a custom field to the AD system in 2N to transform the DDI to the 7 digit Extension like so

So essentially now we have created two records that will be identical and we can now match a User in AD to an Avaya Extension. (assumptions are that there is a level of consistency in AD of course, or that needs remediating before you begin). Let’s assume you do or this blog will be an encyclopaedia. This quick logical diagram may explain it better

OK, so now we are ready to start discovering!

2N is very powerful, so I am going to skip a lot of things, so you’ll have to just accept there will be some blanks in this. You approach the discovery from the AD system down to the source systems. i.e. You want to begin with AD users. The you want to find how many AD users have an Avaya extension. So you need to add an Avaya column to your report and then perform a filter on it to give you the data you’re after.

In each list, you can jump systems. Starting in AD, when you add columns, you’ll notice in the column list different systems e.g. primary extension. This is the user’s Avaya (or Cisco) settings

When you want to add a column that doesn’t natively belong in the top-level report you’re trying to produce, you have to jump systems and then add them in.

Bad example of a field but its only for screenshot purposes. The goal is to get AD data alongside the users Avaya data in the report, so you’ll be able to produce reports like this

Now that we can see both AD and Avaya data, we can filter this report to give us all the users who have an Avaya extension. At a very basic level you could apply something like this e.g. AD extension is equal to Extension in Avaya.

This will update the list to show all users with an Avaya extension match

Now obviously the filters are going to be more complex and unique to your scenario but whatever they are the goal is to produce two lists per site your migrating

  1. All the users that you know have an Avaya extension
  2. All the users that you’re unsure of because there is no match to an Avaya Extension

It’s the second list that you need to focus on to remediate. There will be some that you can, some that are false positives (e.g. shared numbers etc.) but you can work your environment down iteration by iteration until ultimately you get to a point where you have a list of users in a site that are potential targets for migration.

Now you have the list of users you can potentially migrate you can focus on their dependencies and configuration.

In Part 4 I will talk about this in more detail and show you how Unimax Migration Pro can help towards making this a simpler process for you.

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

Migrating from Avaya to Skype for Business – Part 1 -Where to Begin?

I am going to be writing a series of blog posts of my experiences migrating global Avaya deployments to Skype for Business. These posts will focus more on on-premises migrations, but the framework and methodology can be applied to Microsoft Phone System also. I’ll do my best to call out the differences as I go. I must also state that this blog series will focus more on the process, architecture and migration execution than the interoperability required between Avaya and Skype for Business.

I also acknowledge Kevin Martins’ Technet blog series on the same topic, and you should read his blog series too for enrichment. I hope to complement his great suggestions by imparting my experiences when dealing with global customers.

When approaching these types of projects, you often don’t get a true sense of scale or complexity immediately. I can tell you now that whatever you think you’re going to be in for will be vastly optimistic to say the least compared to the real-world landscape that lurks quietly behind the login page.

Where to begin? This is often the most tricky question to answer. You have so much to do that you just cannot easily see a starting point. Experience has taught me that you just don’t walk in and pick a system, log in and begin making decisions and designs off that. You have to approach this from a migration architecture perspective.

The first question you should ask yourself is, what is the objective?

To give you an idea, you’ll probably get the objective from the customer e.g. “Migrate 60,000 users globally from Avaya to Skype for Business while retaining DDI and features”. OK, this is a pretty ambiguous statement, so let’s break this down into expectations.

  • The customer expects you to migrate 60,000 users to Skype for Business
  • The customer expects you to migrate their Avaya station features to Skype for Business
  • The customer expects you to retain the user’s DID when migrated

Now we need to unpick each of these expectations into what the challenges these expectations are going to have on your project. What do you need to consider, what are the common and edge cases you expect to encounter? What are the limitations that will affect your ability to meet the expectation? What technical process do you need to undertake to execute the expectations?

Taking the first expectation “The customer expects you to migrate 60,000 users to Skype for Business”, let’s break this down into challenges, in no particular order of precedence:

  1. We know that the Avaya configuration will generally be inaccurate, contain redundant configuration that will cause problems in identifying real users and extensions
  2. We know that to migrate 60,000 users is not the complete requirement. What about common area phones, meeting room devices, shared office phones, analog devices?
  3. We know that we are likely to encounter users with multiple extensions, so I tend to approach these types of migrations from a total number of extensions view point, than users.
  4. We know that we are going to have challenges identifying where each user or station is physically in the office. Yes we may be able to say extension 12345 is located in Buffalo, but which floor?, which office? Which desk?
  5. Does the customer expect you to remove Avaya stations from location post / during migration? How are you going to achieve that if point 4 cannot be answered?
  6. How are you going to schedule migrations of these users? Do you need to consider personal holiday schedules, departmental and business wide change freezes etc?
  7. Do you need to provide training material for these users in advance of migration? How is that material going to be delivered? How are you going to ensure that the user completes the training before migration?
  8. What about on-going system moves, adds, change, deletes? On a 60,000 user migration this is probably going to take a year, may be two to complete, the Avaya configuration is not going to remain static for this duration, so how are you going to handle late arrivals and departures?
  9. How are you going to handle exceptions? What happens if a user is missed, or the wrong user is migrated due to a data inaccuracy? Do you have a back-out plan?
  10. Does the user have the right equipment and infrastructure to support migration? Is their laptop still running XP for instance? Does it meet the minimum spec for SfB? Do they have the appropriate peripherals? How do you discover, decide and remediate?

These are 10 of the most common questions to ask yourself when trying to assess the magnitude of your deliverables.

Now let’s take the second expectation “The customer expects you to migrate their Avaya station features to Skype for Business” and break that down into challenges:

  1. We know that we cannot feature map Avaya station features to Skype for Business on a 1:1 basis. SfB is different to Avaya and as a result there is going to be some changes to the way in which users will use their UC client and features. There are of course some features that will migrate, and these should be maintained throughout migration for maximum end user satisfaction. But how are you going to do that? You know you’re going to need a feature matrix to show what is migratable and what isn’t.
  2. How do you deal with those features you cannot migrate? Are they redesigned? If so, does it fit within native SfB or do you need additional software? Can business engagement help? Or training and awareness to reset expectation?
  3. What about stations that have dependencies on other stations? E.g. bridged appearances, team call buttons, coverage paths, vectors, remote call coverage, off-pbx etc. etc. You know that this is going to be a significant challenge because you’re going to have to ensure that all dependent users are migrated in the same evening so not to break the voice dependencies. How are you going to find out all these dependencies?
  4. What about if these users have cross pbx dependencies too? What happens if there are call flows that hop between PBX systems? How are you going to handle those? Do they all have to move in one go or can there be a split-brain scenario? Geography may be an issue especially if you need to provide on-site hands.

Taking the last expectation “The customer expects you to retain the user’s DID when migrated” and breaking this down into challenges:

  • What infrastructure is needed to support this? Do you need SBCs? What about PSTN call delivery? How is that going to be handled? Still via Avaya or moving to SfB SIP?
  • How are calls going to pass between Avaya and SfB in the various external and internal calling scenarios?
  • How do you maintain extension dialling across systems?
  • What changes need to be made to Avaya and SfB during migration to switch call delivery?
  • Is there number porting required if the carrier or service is changing? Who is in charge of that? How are you going to ensure all parties are synchronized during migrations to ensure migrations can complete?

These are just some of the challenges you will face on projects like these. This isn’t an exhaustive list and some will be unique to your particular environment. It may seem like a daunting prospect now but at least you understand the customer requirements properly. Now that we have identified the challenges of the objective, we can start to design the approach, solution and customer journey. I will discuss the challenges and the solutions to them later in the series, but for now it is clear that you’re going to have to approach this project in a structured and phased manner.

Broadly speaking, you’ll find yourself creating the following phases:

  1. Discovery
  2. Remediation & Design
  3. Mobilization
  4. Proof of Concept
  5. Pilot
  6. Migration
  7. Post Migration Clean up
  8. Project hand over and closedown

I cannot stress enough that the discovery phase is the most important phase of this kind of project. It lasts the longest, requires the most in-depth research and it underpins the success of the overall project. Get it wrong here, and the entire project will be in trouble. I’ll discuss the inner workings of the discovery phase in Part 2, but for the purpose of this introduction to the series, I will define each of these phases at high level.

Discovery

Discover the physical, logical and functional architecture within the customer environment. This will include detailed technical and procedural discovery documentation that highlights considerations that could constrain or shape the migration project and possible bottlenecks that need to be remediated to support the migration and end state. Discovery of internal processes such as MACD, Certificate provisioning that could delay or shape migration activities and schedule and a high-level plan of how the entire project is going to be executed once you’ve converted pre-sales hypothesis into hard fact based on the customer environment.

Estimated length: 2 months

Remediation & Design

Submission of remediation activities required to ensure the project success to various team owners. These tasks could be physical, logical or configuration changes that are required before migration can begin. This phase can last x amount of time and is largely dependent on quantity & complexity of remediation’s, size of customer and their ability to action remediation tasks within sensible time frames.

Estimated length: Typically, this phase can last anywhere between 4 and 8 months. The low-level designs on how users and services should be created based off facts along with any pre-requisites needed to deliver.

Mobilization

This phase is where you begin deploying your migration software, configuring pre-requisites such as deployment of site SBCs if needed, voice delivery architecture, station grouping and dependency analysis etc. Project planning the migration, defining which sites you are going to concentrate on and in which order. Building of the basics needed to execute a migration; including scripts, build sheets, pre and post migration checklists and basically everything you are going to need to technically and procedurally execute and end to end migration. Also, the customer should be looking in this stage to modify their internal provisioning process to enable new users on Skype for Business by default, rather than Avaya. If this is not done, then you’ll never complete migrations due to continuing onboarding into Avaya.

Estimated length: 2 months

Proof of Concept

In this phase you will test your process end to end technically using test scenarios to ensure that any basic errors in process or technical capabilities are identified and resolved before they impact a user. This is the first time that you will get to prove and ratify your solution.

Estimated length: 1 month

Pilot

Once you have ratified your solution and eliminated all the low hanging fruit issues and are relatively confident that your approach is solid, it is time to execute it in the real world. A pilot stage is needed to select a small number e.g. 200-400 users who are relatively open to participate and have a mixture of basic and complex migration needs. The pilot stage should be executed in the same manner and approach as you would large scale migrations to acid test your end to end solution against real customer scenarios and real user feedback. Use the feedback to learn and improve your process and when you’re confident they have been ironed out, standard migrations can take place.

Estimated length: 1 – 3 months

Migration

This stage is what you have been building up to. If you’ve done your work properly then this stage should be the most exciting and rewarding for you. Here you’ll be executing your migrations at scale and ramping up to several hundred users per night. By this stage all your planning, documents, technical capabilities and procedures should be running in perfect synchronicity.

Estimated length: Dependent on number of stations to migrate and how many migration windows can be granted per week. Assume your maximum ramp up is 200 users per night on a 4 day a week schedule with 60,000 users = 800 users move per migration week / 60,000 = 75 weeks / 4.3 = 17.5 months roughly, but factor in public holidays, change freezes etc. This is more realistically 24 months in linear form.

This can be trimmed in by dedicating regional migration teams to perform simultaneous migrations around the clock. Let’s assume that 60,000 users are equally split over the 3 major regions, AMER, APAC, EMEA. So, on average that’s 20,000 users per region. Now you can perform 600 global migrations per day (due to time zones and personnel) over 4 days a week = 2,400 users per week / 25 week global duration or just around 6 months. Factor in holidays and change freezes, you’re looking at around 10 month is reality.

Post Migration Clean up

So now you have moved everyone over to Skype for Business. But what about Avaya? Well if Avaya is staying for the medium term serving endpoints that couldn’t migrate such as contact center agents, analogs etc. it may make sense to clean up the stations configuration you have migrated once you’re confident roll backs are no longer needed. If Avaya is simply going into the skip, then clean-up is not required to the same granular extent, just simply trash the system configuration instead.

Estimate length: 1 month

Project Handover and Close down

The phase everyone loves. The time for beers, parties and pats on the back!. Here this is just about closing out documents, finalising them, handing them over to BAU teams and removing any migration configuration that is no longer needed. Often the latter is forgotten, but its best practice to leave the new environment in a clean state for ease of administration from this point forward.

In Part 2, I’ll discuss the discovery phase in more detail, which will answer some of the challenges we identified in this post.

%d bloggers like this: