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:
- Migration retaining DDI
- 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:
- Enable the user for SfB Enterprise Voice
- Assign the user their Line URI including extension number
- Assign the user a site dial plan
- Assign the user a user voice policy
- Configure the user’s call forwarding settings
- Configure the users boss / admin and team call settings
- Add user to Group Pickups, Hunt Groups, Shared Line Appearances etc.
- Enable the user for Exchange UM
- 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.