Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Converting from 4 to 5 digits in PBX
- Thread starter dallas1
- Start date
Avaya uses a tool call 'ProVision', which is not available to customers. From personal experience, there are so many hooks associated with changing the dial plan that you may find it cost effective to let Avaya/Business Partner do it.
Kevin
Kevin
phoneguy55
Programmer
Agreed. Stay away for doing this yourself, you are asking for a mess. The cost is very low compared to the amount of hours it would take someone to do it without provision.
mikeydidit
IS-IT--Management
I have not had time to look into this personally. I was talking with a friend that works for a vendor and he told me the new version of Avaya ASA or Integrated management will do this for you. You could play with it and see if you are intent on doing this yourself. I too would recommend a BP but this may be a simple way of doing it.
"You don't stop playing because you get old. You get old because you stopped playing."
"You don't stop playing because you get old. You get old because you stopped playing."
I've done this just using ASA and the duplicate command. It took me about 40-60 hours of planning and preparing for a 500 station migration. Then 3 hours to do the actual conversion (with a data mod, not a faster CLAN interface). Followed up with another 8 hours in relabeling phones. If my company wasn't so cheap, I would have preferred Avaya do the work. Here's a basic breakdown of what I did:
1. Duplicate special stations that don't meet normal template standards. They should be assigned to X port.
2. Have ASA X port all stations.
3. Have ASA remove all stations (those with MWI on will have to be removed separately).
4. Have ASA create new stations with 5 digit dial plan. A separate import is required for each station type and template.
5. Modify any bridged appearances, busy indicators, vectors and hunt groups to reference new 5 digit extensions.
As you can see, there is a lot to do and make sure you have all your bases covered. There's no way to simply run a script, as everything needs to be carefully planned out and executed.
1. Duplicate special stations that don't meet normal template standards. They should be assigned to X port.
2. Have ASA X port all stations.
3. Have ASA remove all stations (those with MWI on will have to be removed separately).
4. Have ASA create new stations with 5 digit dial plan. A separate import is required for each station type and template.
5. Modify any bridged appearances, busy indicators, vectors and hunt groups to reference new 5 digit extensions.
As you can see, there is a lot to do and make sure you have all your bases covered. There's no way to simply run a script, as everything needs to be carefully planned out and executed.
My advice is to have Avaya assist you with this conversion. We performed a conversion from 4 to 5 digit dial plan 5 years ago and it is large undertaking impacting not only your dial plan but trunking, speed dialing, ACD, Call Vectoring and your Audix network-everything is touched. Also you will need to convert multiple sites concurrently if you are using DCS+ or Audix networking.
Iggy
Iggy
i recently did a 4-5 digit conversion using Provision myself for a 6,000 station switch, 5,000 agents & 820 vectors. Using excel and formula's, the manipulation of digits was the easy part. The hardest part was going into each station & vector to check if any 4-digit references existed. That was probalby the largest undertaking with the most room for error.
The stations i could deal with when loading everythign with Provision, because i could see the errors and then go back and fix the file where there were mistakes. But the vectors would only tell you where collect digits & announcement statements were wrong, not the route-to's so those had to be fixed manually and looked at a few times. I had a surrogate 8700 server in my house that i used to load the translations and build essentially a translation (xln) file and after i was done, i took the translation card, on the night of cutover, put it into the 8700, did a restore of that file, then did a "drestart 1 4" command and it brought everythign back.
First day issues were minimal really on the pbx side and definitely not big that couldn't be fixed. Call Center worked great and just little station issues had to be fixed.
It was probably the biggest undertaking i've done but it was a short time frame and we met it really well. It probably took a total of 30 hours with the Provision work on this. 3 full days of me and my counterpart goign thru the vectors & stations, which i had to look over anyway before importing.
So, it can be done.
The stations i could deal with when loading everythign with Provision, because i could see the errors and then go back and fix the file where there were mistakes. But the vectors would only tell you where collect digits & announcement statements were wrong, not the route-to's so those had to be fixed manually and looked at a few times. I had a surrogate 8700 server in my house that i used to load the translations and build essentially a translation (xln) file and after i was done, i took the translation card, on the night of cutover, put it into the 8700, did a restore of that file, then did a "drestart 1 4" command and it brought everythign back.
First day issues were minimal really on the pbx side and definitely not big that couldn't be fixed. Call Center worked great and just little station issues had to be fixed.
It was probably the biggest undertaking i've done but it was a short time frame and we met it really well. It probably took a total of 30 hours with the Provision work on this. 3 full days of me and my counterpart goign thru the vectors & stations, which i had to look over anyway before importing.
So, it can be done.
I agree with everything said above and to sum it up: If you have stations only (even a large number), it can be done without ProVison and by yourself.
If you have a CallCenter with VDN’s, Vectors and other cool stuff, I would strongly recommend paying AVAYA to do it if you can’t get your hands on ProVison
Regards Frank
If you have a CallCenter with VDN’s, Vectors and other cool stuff, I would strongly recommend paying AVAYA to do it if you can’t get your hands on ProVison
Regards Frank
i don't know about ASA being able to do what Provision can, not even coming close. Provision essentially keeps everything about a station, from the features set to "y" and the buttons. ASA can't do that. And you'd have to make sure you have enough licenses to essentially duplicate stations so that you keep everything but even that is tedious.
What i've essentially done is do what Avaya usually would do on a "blowback". Loading it into a surrogate, building the xln file and delivering to you the xln file to simply load on the active partition of the 8xx0 server. Its the best and most efficient way to do something like this. It just takes dedication & real focus and time. Avaya does have access to things in Provision that we as BP's don't tho that can do the dialplan conversion a lot easier, but you do what you can with Provision.
What i've essentially done is do what Avaya usually would do on a "blowback". Loading it into a surrogate, building the xln file and delivering to you the xln file to simply load on the active partition of the 8xx0 server. Its the best and most efficient way to do something like this. It just takes dedication & real focus and time. Avaya does have access to things in Provision that we as BP's don't tho that can do the dialplan conversion a lot easier, but you do what you can with Provision.
- Status
Similar threads
- Locked
- Question