Post-upgrade Pros and Cons

3 Reasons not to assume and always test

In this post, ‘Post-upgrade Pros and Cons,’ you get to read how we can fall into the trap of feeling confident that all went well with a system upgrade, taking for granted some vital testing steps after making the upgrade permanent and not following the basic steps of troubleshooting.

A couple of weeks ago, I got the chance to help one of our clients upgrade their voice solution, which needed some reconfiguration on their phone sets to match the new parameters implemented by us. There were three sites involved in this upgrade and I had two other engineers helping me out at the remote sites.

I am a big proponent of having checklists and test forms for each job. During the conference call, I asked the rest of the team to follow the same test plan that I had developed. To my understanding, everything had been tested; however, a week later the customer called me to complain that one of the remote sites was having issues after the upgrade.

I have included the reasons why not to assume and follow these guidelines to help you avoid making the same mistakes=

• 1.- Deliver a clear message
• 2.- What to look for while testing?
• 3.- Is the customer honest?

1.- Deliver a clear message

While the upgrade is in progress, have the rest of your teammates review the test plan that you  put together. Breaking down each step even though those steps might seem very simple. e.g Line programming, bridged-appearances showing different, time of day not showing, etc.

By not having the phone the exact way it was pre-upgrade, you owe the customer a brief end-user training to explain how the new features work, or why the existing features are labeled differently.

2.- What to look for while testing?

By now you should have a good understanding of the day-to-day customer business operations. Have them simulate all types of scenarios post-upgrade. In most cases, these should work the same, but I have found that some features might need to be tweaked in order to work as they used to. From ring delay timers, beep while listen, dialing parameters, and phone display features, among others.

Remote Workers and Software Apps

These should also be tested the same way, having them operate their VPN-Phones, mobile and desktop applications as they normally would.

3.- Is the customer honest?

This is a big issue that we all encounter whenever we replace or upgrade any type of hardware or software. From my personal experience, I tend to test every variable possible to see what fails and what works. I also check the upgrade notes (PCN / PSN) to verify that any existing related issue will be fixed in future upgrades. If not, I immediately contact my team and make them aware of the situation.

By testing pre-upgrade, you avoid distrusting the customer, and assuring that any lingering issues post-upgrade are related to the system, where the manufacturer most be engaged to try to patch it/fix it.

Errors / Alarms / System Events

These can also be helpful when identifying system fault, displaying time and date of any alarm or system error, helping us pinpoint defective devices.

We made the mistake recently of replacing an old NEC system with a G430/S8300E where the IP Phones were getting registration from an old crossfire at the Core system, and we thought that it was related to WAN. After intensive troubleshooting, and testing CLAN and MEDPROs, we found a bad MEDPRO board.

Have you encountered any these issues?, and  What did you do to overcome them?

Resources

Download the Post-Upgrade and Installation Forms

Lifecycle Summary Matrix and PCN and PSN Reports

Upgrading Your PBX