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

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.


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.


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


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


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.


Leave a Reply

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

%d bloggers like this: