For those of you who work in the Skype for Business ecosystem, you will be familiar with the terms End User Profiling Methodology, Call Quality Methodology, Skype Operations Framework, Roll-out Adoption Success Kit and other framework methodologies that are designed to help guide customers along the Skype for Business journey. You may not of heard about the Migration Methodology! There is one reason as to why you haven’t and that’s because I have just made the term up!
However, you all know it already, whether you realise it or not. You follow it in your own way and work around it based on situation needs. The purpose of this post is to call some order to this process in an attempt to provide an easy point of reference for everyone.
So what is the Migration Methodology?
When you read about Skype for Business Enterprise Voice and how to migrate from Legacy PBX systems, you will come across two common trains of thought. From the marketing perspective of Skype for Business you will hear how easy it is to enable a user for voice “It’s just one line of Powershell, simple!” and from the technical perspective you will read of all the level 400 permutations of how to integrate two systems together, common issues and the nuances along the deployment journey.
However, once you have Skype for Business and you have created your interconnects between your various voice platforms, what then? This is where some of us (including myself at times) goes “Errr…. how do i migrate these users?”
This is where the Migration Methodology comes in to play.
The Migration Methodology is a framework I have designed for myself to follow to help me through the migration process from a business process perspective, and now sharing with you. The framework works on three core areas that can be executed simulaneously in order to help you work towards a migration ready state. Again, the Migration Methodology is a business process framework that sits on top of the technical methodologies you are more familiar with but comes after profiling. Think of it as your “Migration Action Plan”.
Understanding the Challenges
When Skype for Business is deployed to a customer environment, there always seems to be this mad rush to get users on a pilot and then full migration as soon as possible. Barely time has passed since your last configuration Powershell command and the customer demanding BAU on all modalities. This instinctive rush to realise investments immediately is the single, most serious contributing factor to project failure.
Rushing BAU will lead to important considerations being overlooked, user’s will be impacted, perhaps they won’t have sufficient training to understand what they need to do, or worse, they don’t even have the tools to complete their tasks. Problems may arise through network impairments, maybe a port or two is blocked at some remote site, maybe you’ve missed that analogue fax machine hiding in the corner of the staff room that only one person uses once a month to send one fax? Perhaps as a result of the pressure and rush, IVRs, Hunt Groups or boss/secretary scenarios have been missed forcing you to roll back.
The point is, that these issues will be determined in the customer’s eyes as “Skype for Business doesn’t work!” and considered a failure, waste of investment and that you as a systems integrator are at fault because you should have seen this.
This situation annoys me, because I know that it is not Skype for Business’s fault that the customer’s security team have locked down too many ports, or the IPT telephony incumbent failed to provide accurate information on existing workflows, or the customer failed to properly audit their requirements and pass this information on (even with repeated requests), and I have busted a muscle to make sure I have covered everything. Yet the customer sees just a fail and that really, really hurts my pride.
It’s a huge challenge, so follow the Migration Methodology and ensure that everything runs smoothly.
The Migration Methodology
I mentioned that the Migration Methodology concentrates on three core areas. But before we start down this path you must put agreements in place with your dependent departments and suppliers. This agreement is referred to in project management land as a RACI, or Responsible, Accountable, Consulted and Informed. The purpose of this is to ensure that everyone is aware of their responsibilities and impacts of not performing their end of the bargain. Get this agreement in place and ensure everyone signs up to it.
Now you’re RACI is defined and in place, you are ready to learn the Migration Methdology.
User readiness is all about looking at the end user functionality and BAU tasks to ensure that you are able to represent these in Skype for Business once migrated as well as preparing the user for the migration through effective communication and training (End User Adoption – RASK).
The first stage is Legacy User Features. Here you need to ensure that the user’s legacy workflows and dependencies are captured, this includes:-
- DDI/DID Information
- Hunt Group membership
- Call Forwarding scenarios
- Boss / secretary scenarios
- Group Pickup or Share Line Appearance
- Team Calling settings
It is important especially with the more advanced workflows to pay particular attention to the user’s way of interacting with these as subtle or big differences may be experienced when these are migrated to Skype for Business. This helps define your training strategy for your users and you can tailor it to include “What to expect”.
Once you have gathered this information, you can compare this to native Skype for Business functionality to determine whether or not you can support this user’s feature set. This step is called Parity. Use this step to define your own feature comparison matrix for users. It is important that the matrix contains four columns of reference:
- What features currently supported globally by the legacy PBX
- User dependency on these features
- Supportability in Skype for Business
Columns 2 and 3 need not be more than just tick boxes. However, the matrix will identify areas that you cannot support natively, or can but requires a different way of operation. For these features use the mitigations column to recommend to the customer what is required in order to meet feature parity.
Use this collated information to help you determine the required Skype for Business features that are going to be needed. This won’t be an exhaustive list, but looking at end user functionality will give you an insight into 90% of the voice structure you need to think about when migrating. This information will help you determine the number of hunt groups, IVRs, whether the infrastructure will support the load and whether you need additional tooling such as SefaUtil Server (www.Landiscomputer.com) in order to complete your migrations.
Once you have this information a critical step is to seek Customer Sign-Off. Present your findings to the customer and fully explain the outcomes of any mitigations. Don’t just hand them the spreadsheet without explanation and expecting them to understand the implications of what you’re asking them to sign-off. Keep them on-side but ensure that you get physical sign-off that they are happy to proceed based on your findings.
Once that has been achieved, you can proceed to Communication & Training. Here invoke the Roll-out Adoption Success Kit (RASK) provided by Microsoft to get the users aware and trained. At this stage you should be at least planning a date for their migration. Remember, the end user is your most effective and at the same time destructive asset in the migration process. You need to keep them on your side as the success of the project hangs on their feedback. So communicate, communicate, communicate with them. One trick I use is to set a migration date for them, inform them of that date and then allow them the option to choose an alternative date if the one schedule doesn’t fit in with their personal circumstance. Another tactic is to word your communications in a way that can be perceived to be empathetic and understanding to user situations, making users feel IT and the business is there for them and they don’t need to worry.
This gives them a sense of involvement and that IT are really listening to my needs as business user and my personal situation. This makes them more receptive to change and will be more enthused to adopt. One critical step here before we move on is to actually take reasonable steps to ensure users due for migration have attended training courses. You don’t want to migrate a user who doesn’t know how to make a Skype call. So do your best to ensure compliance.
Baseline is a step to validate that users who already have Skype for Business accounts for IM & P have the correct base policies assigned to them. This is not really a voice configuration step, more of a house keeping step to ensure the right client, external access, conferencing policies are set, Exchange UM is configured ready for them in languages they understand etc.
Then you end up at the Ready Stage
Workspace readiness is all about assessing whether the end user has the correct tooling in order to complete their tasks once migrated. During the Workstation Assessment here you want to audit the users laptop or desktop to ensure it meets the minimum agreed specification for your deployment. This includes:-
- Ensuring hardware specificaton meets requirements of Skype for Business Client
- Ensuring the Operating System is the correct version and all required patches are applied
- Enuring the correct Skype for Business client with the same patches are deployed to all users
Ensuring workstation compliance means that you have a supportable baseline on which to migrate. A large percentage of adoption failures are down to users using mixed breed software e.g. Lync client and Skype for Business client. If the training is delivered using Skype for Business UI then this is what the end user is expecting, not the Lync 2010 client!! So, while customer teams may moan a little it is absolutely critical that machines are baselined consistently across all the estate.
Environment Assessment, this is assessing the users working environment e.g. their desk and connectivity at their desk. Here you should employ your own workspace assessment (talk to your Health & Safety officer), but the key objective here is to ensure that their working environment will actually support Skype for Business. I am particularly referring to desk phones. You want to make sure that when you send them a Yealink T48 for instance, there is enough room on their desk! Connectivity here, you need to work with the networks team to ensure that if a desk phone is required, is there POE, or does there need to be a power adapter supplied with the phone? If a power adapter is required, talk to the estates team to find out if the desk has sufficent power socket capacity etc. If a legacy desk phone is to be removed, how does the user connect to the network? Through the legacy desk phone internal switch, or directly to the LAN using a wall socket? If via the legacy phone, will connecting the laptop to the wall socket without the phone cause any problems such as wrong VLAN assignment?
Peripheral Assessment, you should have profiled your users, so you will know what peripherals users need to perform their tasks. However, user’s may already have some peripherals capable of working with Skype for Business, in particular headsets. Use this time to audit headset ownership, make and model and work out whether they need to be replaced. If devices are not on the certified list of peripherals, replace them. If they are, then attempt to discover if firmware needs updating to bring them up to standard. Use this information and ship the required peripherals to the user to ensure that they are there ready for migration. Seek receipt confirmation of the peripherals (headset, desk phone) so you know they have arrived.
Again, Cutomer Sign-off is invaluable here. Using the information you collated in the above assessments, send the report to the customer that includes all the findings and remediation steps required. Whether they have been completed satisfactorily or outstanding. Flag any perceived issues, such as insufficient desk space or resources to them so they can remediate as necessary. Obtaining sign-off on mitigations and risk acceptance is vital to your success.
Once the workstation is prepared, you are now at the Ready State.
Up until now we have been focussed on end users, because they are the most important element of the project! However, now it’s time to focus of the back end functionality that will form the building blocks for end user experience.
Create a test plan for each site and in this test plan you will need to capture the results of the configurations and events below.
Voice Settings here is where you need to start pre-configuring dial plans, voice policies, voice routes, PSTN usages to meet your end user calling requirements. It is recommended to use user based policies with a site naming convention to maintain consistency throughout the configuration, e.g. for a site in London
|Voice Policies||UKLON-INT-EMG, UKLON-NAT-INT-EMG, UKLON-NAT-MOB-INT-EMG, UKLON-NAT-MOB-INTL-INT-EMG|
|PSTN Usages||UKLON-EMG, UKLON-INT, UKLON-NAT, UKLON-MOB, UKLON-INTL|
Even if there is the same route, PSTN usage for all sites, create individual site based user policies. Not only does this provide a reference point to the user’s location, but also provides greater granularity and flexibility to meet future business needs. Use the test routing case scenario builder within Skype for Business to validate policies and routes. Record in your test plan.
Site Call Flows, here you should be configuring hunt groups, IVRs, call park orbits and unassigned number ranges. Hunt Groups and IVRs can be created ahead of time using temporary Line URIs in order to prove flow and functionality. It is important here that the customer validates the hunt group and IVR workflows before go live as these will be the customer’s business face. Once these have been validated during migration all that is required is to change the Line URI to the correct one. Capture these workflows in your test plan.
Amenities reference site devices rather than end user owned, such as common area phones (CAPs), DECT servers etc. Here, you should be discovering locationing and mounting requirements, and arranging any contractors to implement fixings. You should also add the desk phone to your provisioning solution and ensuring that the correct profiles and firmware are assigned ready to be deployed to the phones. DHCP scopes configured ready to support phone deployment too.
Interop here you should be looking at any site interoperability – do you need to integrate with door access systems, meeting room devices, lift phones etc. This should be configured at this stage assuming that you have identified the hardware requirements needed to interop between Skype for Business and other systems. Test and confirm interop with test accounts and enter results in your test plan.
For the Connectivity stage here you should be focussing on bandwidth policies, quality of service and modality testing. Use the network assessment documentation from Microsoft to model your bandwidth policies based on your available bandwidth, ensure the QoS GPOs are assigned the the user’s workstations and use GPO results to validate that the policies are being applied. From a workstation at the site perform a full modality test with an endpoint at another site to confirm P2P A/V, Conferencing, Voice, Federation etc. will operate as expected. Use packet captures to ensure that ports aren’t being blocked and that the traffic is being QoS marked as configured. From the other side of the conversation check that data packets arrive with QoS marking intact to ensure the network is adhering to DSCP. Use snooper to trace the conversations to ensure that media is flowing in the intended direction, bandwidth policies are being applied and that there are no impairments affecting successful delivery of traffic such as SIP signalling.
Record your results and findings in your test plan. Once the test plan has been completed you will be able to determine the probable factor. Any areas that are identified as fails, work with the customer to remediate. Once remediated, re-validate against the test plan. Once all tests have passed, obtain customer sign off. This is important because they are validating that the backend configuration has been configured to meet their functional needs.
Once sign off has been obtained you reach Ready state.
It is good to note hear that these three core steps do not necessarily need to run in linear mode. By this I mean you don’t need to complete user before workspace before site readiness. Instead these three core steps work side by side, in tandem and you should reach the ready state across all three stages at the same time.
If you do not have three ready states you should not proceed to migration execution. Instead push back until you have three green lights. This way your migration will be a success, I promise you. However, be prepared for the odd curve ball!
Using this approach to migrations, based on my experiences is the best way to manage a migration within a business. The reason why I have not included test plans, scripts or other literature here is not because I don’t want to share IP, but because it is somewhat bespoke to each environment and customer expectations are different. Use this framework / methodology to plan your own road map and this will help you determine the most appropriate migration time frame and schedule for you.