To upgrade or not to upgrade Dynamics GP

A client of ours uses Encore's Recurring invoicing in conjunction with Nodus's Credit Card Advantage. They are still on Great Plains 8.0 and are using EFT transactions as well. The need has arisen for customers to use multiple EFT bank accounts for different contracts in Recurring Invoicing. Can't be done in 8.0 but in 10.0 you can have EFT accounts attached to different address ID which can then be used as a billing address on the contract.

My answer to them is you need to upgrade to get that functionality. The accountants response was "What the heck. Why haven't we updated yet?" I would have liked to say "I've tried to get you guys to upgrade for a year or more now" but instead I was diplomatic and said "I think your IT staff is in the process of following some of our recommendations to move up to the new system. You may need to check with them."

Coming from the Partners viewpoint I usually say after one or two service packs you can upgrade whenever you like. That's not always necessary/feasible. The real issue comes as upgrading Dynamics GP (or any software for that matter) comes with certain costs. A few are listed below:

• Annual maintenance costs from Software vendor- typically a percentage of you system list price


• New hardware to meet new software recommendations


• Consulting or in house time to do test upgrade - includes time spent verifying data upgraded successfully, 3rd party application testing, interfacing with end user to verify everything looks ok, etc.


• Consulting or in house time to do production upgrade software, install clients, update reports, install 3rd party applications, upgrade 3rd party applications, and fix modified reports that don't update, etc.


• Downtime for current employees during upgrade


• Training users on new features or procedures


• Ineffiencies while using/navigating through a new system


• Increased support costs with Partner after upgrade specifically related to new functions and procedures

So why in the world would anyone volunteer to update their system as it seems like a new version is released every 6 months? I've listed a few reasons to upgrade below:

• Increased effiencies with new hardware, system performance with updated software


• Older software is not supported and you have to find a dinosaur that charges $400 per incident to fix anything. (I know the two last dinosaurs that support GPA, man are they old and ornery)


• New technology only available with new versions of software - Business Portal, eConnect, Sharepoint, SSRS, etc.


• New versions are being fixed, developed, enhanced so in theory you should have less support calls regarding system bugs


• Upgrade costs are minimized when system moves to the next version up instead of making a 2, 3, or more step move. See Mariano's blog for upgrade paths.


• Training usually is less involved as there are not 2 or 3 sets of "What's New" crammed into one training session


• Newer version of software is typically more developed. If you are still using the first version of CRM, RMS, Analytical Accounting etc., I'd suggest you are akin to gnawing your foot off to get out of a bear trap (Montana metaphors, got to love it).

So what do you think? How do you determine when to upgrade?

What are some of your reasons To Upgrade or Not to Upgrade?

Here are a couple of links to formulate my thinking:

• MBS Marketing blog (of course they want you to upgrade)


• David Musgrave better not convince MBS to extend 8.0's life cycle policy again


• Andrew Karasev

How do you install a large number of workstation after an upgrade efficiently?

Recently we have discussed best practices about upgrades in our company. One of the big challenges in an upgrade is installing a large number of Dynamics workstations at the appropriate time with minimal user interruption as possible. Installing Dynamics has always been a pain. MBS has approached fixing this issue with their mass deployment tools but they never work and it usually ends up easier to do the installation manually. Depending on the installation you could spend 15 mins - 40 mins per workstation. Launching the installs simultaniously (3 at a time in the same area for example) may cut time a bit but still a huge pain.


This led to a series of responses by our technical team. Here is a summary from one of our team member Jason Young. Summary of response below:


One of the tricks I have used many times to minimize downtime for large rollouts is to leverage imaging tools like Acronis True Image. This tool lets you take a picture of a server or servers and redeploy them in a virtualized environment or dissimilar physical hardware. In essence, you can take the customers environment back to the office for the test upgrade without risk of downtime or impacting day to day production of the customer.

Imaging gives you some big advantages:

1. You don’t change the state of the customers environment until testing is successful and you are ready for the production rollout. This gives you huge kudos in the eyes of local IT staff.


2. You always have a clean rollback image.


3. You don’t have to bother local IT staff because you are working with an image offsite.


4. You can couple this type of test upgrade with a Terminal Server (which we have and is easy to build) and now you can do your user acceptance testing via web. Again, no customer impact.

To do the production rollout it is always optimal to do a parallel installation, but the obvious drawback is the cost of hardware. For customer without additional server resources, there is another trick that can minimize downtime and customer impact. For customers with a single backend server (single SQL server), you install a name instance of SQL and restore production data to the new named instance.

Here are the advantages;

1. A named instance of SQL means you have to use a different DSN name than the default instance. This means you can pre-install workstations with the new version and point them at the new instance without worry of an accidental upgrade.
2. The current state is not affected so you have a rollback in the event of an upgrade failure. You don’t have to do any type of restore because you never changed the data in the default instance of SQL.
3. You are basically taking a single server and doing a parallel application upgrade. So, it’s an in-place upgrade in terms of hardware but parallel in terms of the application and data.

End of summary.

Discussion: I like the seperate instance of SQL approach. I do this with different versions of Dynamics. I have 9.0 on one instance and 10.0 on another. You'd have to be careful that users do not launch and continue working in the older version instead of the newer version but that can be overcome with training or simply stopping the older instance of SQL when the time is right (probably need to set the older instance to manually start in case of a server reboot).

Anything you do to make this task easier?