Loads of tips, particularly following problems today with a 4.0 to 450 upgrade.......
1) Take a 3.7 HDD drive to site, just in case the 3.7 to 4.0 upgrade fails. Don't forget to run the pre-upgrade check tool first, and resolve any issues before attempting the 3.7 to 4.0 upgrade.
2) Once on 4.0 do some very basic sanity testing, for example can you call in, can you call out, do you mailboxes have messages? If you don't do this, and you run into a problem, you won't know if the problem occured in the 3.7 to 4.0 upgrade or the DMM extraction or application.
Take a backup on 4.0.
3) Ensure you have at least one Unified Messaging (UM) license enabled on the 4.0, BEFORE generating the keycode for 450. It's required to export the voicemail messages.
4) Once on 4.0 apply the latest system update before using DMM to extract the data. The DMM guide mentions pre-requisite patch levels on both the 4.0 and the 450, the upgrade guide does not, unless Nortel have released them following the changes I requested. Also apply the latest system update to 450 before applying the data using DMM. if you don't meet these prerequisites, Nortel won't be willing to help if you raise a case.
5) Save the extracted data to an .XCM file.....depending on the guide, this is supposidly optional. I HIGHLY HIGHLY recommend you do this, so you can run it again if it screws up. Again, I've asked for the upgrade guide to include this. Same goes for saving the output to an excel file - do this too, as you might need it, when things go pete tong. Anything that says optional....don't try to save time by not doing it. There is a good chance the configuration will need some serious manual re-work after DMM gives an innocent looking warning however leaves half the configuration wrong. More on this later - the 'big problem'.
6) You are provided with the option to save all the DMM reports. Do save them, so if you need to report a fault into Nortel, you have this.
7) Save all programming data on the BCM 4.0. This will take some time, however if the configuration screws up, you have this to refer to.
8) Ideally use a spare BCM chassis (if you have one), and install the 450 hardware into it, and not the customers live BCM. This has two huge benefits:
a) Saves time with changing the hardware (if you were not doing the 3.7 to 4.0 upgrade at the same time of course).
b) When you need to reconfigure the telephony because DMM has left the configuration in a sorry state, you can simply logon to the original BCM using a different PC and compare (or refer to the saved programming data or excel spreadsheet I hinted at earlier). The keycode will be generated against the base function tray for the 450, so any old working chassis will do (just watch out its not a redundant option, and you are sent a single fan).
9) Warn the customer that mailbox messages may not copy over. I've had two upgrades suffer the same fate....first one because I did not apply the UM keycode (my mistake), 2nd one they just failed (despite UM keycode, despite latest system update, despite not running DMM across LAN1 - don't upgrade through OAM port as the DMM guide warns voicemail messages may fail). I raised a case into Nortel/Avaya today because none of the mailbox messages ported over (the mbox greetings did).
So the big problem I mentioned.....The DMM hints not exporting data if it somehow refers to something/an extension which is invalid (see the appendix in the DMM guide). This might be relevant. However in my experience ( it makes sense, however I may be wrong)....lets say you have a 3 digit extension. BCM450 has higher capacity, for example 100 application DNs alone plus other system DNs. So DMM / BCM has to 'squeeze' the user DNs and system DNs into maximum 999. Let's say your current DNs are 400-450. After the upgrade, you may find that application DNs have crept into the 400-450 range, which has serious knock on affects so OLIs, target lines, control DNs etc are wrong.
Take another example, from today. This time we had 4 digit DN length. Active DNs 4300-4350 (not exact). Some of this range were again used by application DNs, so DN 4351 & 4354 could not be registered as IP sets, as they came up 'invalid DN'...because after DMM process these DNs were application. Okay I'm repeating myself here, however it highlights that the problem may occur with 4 digit extension, not just three. To resolve, I had to double click on the application DN and renumber it to a spare, then double click one of the spare/wrong IP sets, and renumber it back to the required DN. However this meant I had to go through all the telephone configuration, correcting a lot of it. The DNs that did not clash were generally okay, however I still found myself having to remove some target lines (another thing is the target line ranges change, so you have to look for the pub & priv received to match the correct target line). I raised a case into Avaya today, suggesting they restore the 4.0 backup I provided them, then extract the data, then prepare the data, then apply the data, and see whether they end up with the same mess I did.
HINT: If you can upgrade them to 4.0, then on a different occassion to 450, with a spare chassis you hardware upgrade it, you can reconfigure the telephony by comparing the configuration. If the old 4.0 is not to hand, life might get really difficult, unless you are familiar with finding your way round the 'save programming data' results or the excel spreadsheet from DMM. If you don't produce either, life might end up really difficult as the 4.0 HDD has been removed and will be sitting in a box.
Anyone contemplating a 4.0 to 450 upgrade, I recommend you consider this carefully.
Hope this helps.
regards
paul
