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:
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:
- 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.
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale