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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s