Rose Business Solutions Dynamics GP

I’ve struggled with this question throughout the years. I started my GP life in an organization that did it the blood and guts way. Here was a typical upgrade strategy:

1. Get the OK from a customer that they’d approve our estimate on the upgrade
2. Schedule the day with the customer – usually later in the day Friday to kick off the upgrade of data. (Sometimes the customer could be without a day in their system so we’d do this on a Thursday so we wouldn’t have to charge weekend rates.)
3. Spend Saturday installing workstations, verifying data, cleaning up any issues. This gave us a day in case upgrade failed etc. so the customer wasn’t out of the system for two days in a row
4. Leave Monday as an office day to work through any outstanding issues with the upgradee
5. Sometimes provide training on new version. What’s new type of thing.

A few points to mention about this strategy:

1. Usually the customer was a smaller shop. Total users from 5 to 15 workstations
2. The customer usually didn’t want to spend money on a test upgrade – if we were going to do the upgrade might as well do it once and get it over with
3. Most of the clients we had done upgrades on before. We kind of knew what issues we had in the past
4. Not too customized. Very little mods to windows, VB code, etc. Customized reports were the main issue

The organization I’m employed with now is a much more process oriented firm in regards to upgrades. It would be unheard of to simply show up and do an upgrade. Our typical procedure is something like this:

1. Perform an infrasture review before any upgrade procedures are recommended. This includes hardware/network analysis
2. Perform a test upgrade to uncover any issues. Test on workstations identified as potential problems (older workstations, operating system outdated etc)
3. Training on new version done as client verifies test upgrade
4. After test upgrade, discuss upgrade procedure with client. Determine schedule that provides best timing with customer. Schedule resources from client needed to accomplish tasks for upgrade. (Often IT departement involved to install workstations etc.) Go over issues found in test upgrade and resolve if possible a head of time.
5. Perform upgrade. Install workstations
6. Post upgrade validation from client
7. Client sign off

A few points to mention:

1. This process is used on install bases of 5 to 100+ users
2. Customers often have many customizations to their system with various 3rd parties tying into Dynamics.
3. Process is somewhat customized to meet the clients needs. Not all customers will pay for extensive pre-upgrade discovery. We do require a test upgrade of the data however
4. We still have upgrade issues when we get to the production system but have most of the issues worked out from testing phase. This has increased customer satisfaction overall and I don’t hear from nearly as many grumpy people like I used to

Back to the original question. Are test upgrades really that important? I’m still of the opinion that the correct answer is “It Depends”. If you don’t mind a little bit of blood along the way and the customer is a relatively small shop there can be a lot less planning involved as there is must less risk on all accounts.

But if the customer is similar to the description above, dividends will be paid for proper due diligence. I believe most of the cost of pre-upgrade discovery/testing will be returned and more when the production upgrade is performed without a hitch.

So what do you think? Are test upgrades really that important? Do you have any other procedures you employ in your upgrade process?

4 Responses to “Are test upgrades really that important?”