I've worked with several customers recently who have upgraded Dynamics GP to a new version without doing any prior testing. The upgrade was performed in their production environment. No test environment. No test database upgrade. No testing integrations or customizations prior to the upgrade. Today I was informed of another customer that will be upgrading to GP 2016 without a test environment--just an upgrade of production. Which made me wonder...
While there are probably many people who would rail against such an approach, I'm now asking a serious question: Do you really need a Test environment anymore for a "typical" Dynamics GP upgrade? I'm guessing that many GP customers could probably upgrade their production environment in place without any significant issues.
Yes, there are customers with complex environments that would definitely benefit from a Test environment, and yes, there are cases where upgrades encounter errors that cause the upgrade to fail, but I suspect there are a large number of GP customers with pretty simple environments where a separate environment and extensive testing is not required and would be difficult to justify.
Years ago, before Microsoft purchased Dynamics GP, GP upgrades could be a harrowing experience. Both the GP install and upgrade processes involved many steps and the GP installers weren't nearly as refined as they are now. One of the things I noticed following the Microsoft acquisition was that the GP installation and upgrade process became much simpler, easier, and more reliable. Whereas I used to always recommend setting up a separate test server and performing a test upgrade first, I have worked with several customers recently who have simply upgraded their production environment without any prior testing of a new version of GP.
If you make sure to take good database backups, have a few GP client backups, and have a thorough upgrade plan that has a solid rollback contingency, is it really necessary to have a separate Test environment and perform a full test upgrade first?
Are there particular modules, customizations, environment considerations, or other factors that you think make a Test environment more import? Third party modules? Customizations? Integrations? Web client? On premise vs. hosted? Lots of data or company databases that causes the upgrade to take a long time?
Update: Tim Wappat made a good point on Twitter: Since many companies now run GP on virtual machines, you can easily backup the relevant VMs for quick rollback, and you can also easily clone VMs to quickly setup a "test" environment, greatly reducing the administrative costs of using a test environment to validate a GP upgrade.
Steve Endow is a Microsoft MVP
for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.
He is the owner of Precipio Services, which provides Dynamics GP
integrations, customizations, and automation solutions.
3 comments:
Great question. In addition to the factors you mentioned, some companies consider the billable cost of a test upgrade, the (lack of)availability of in-house staff resources and their risk tolerance for system down time if there are problems during a production upgrade.
I guess it really depends on the customization your install has.
As a customer myself, I did do consulting for a small period and honestly I cannot think of one customer who had an environment without modifications that would require testing.
I know when I upgrade I have 4 dexterity dictionaries that might need recompiling, and lots and lots of .net addins that would definitely not run if not recompiled.
thanks
Hi Steve, thanks for posting about this topic.
I am in agreement that it's not always necessary to have a test upgrade done. Especially with the typical installations. If there are extensive custom screens or custom applications involved, then I would strongly recommend a test upgrade. I think I do more upgrades without the test upgrade than I do with. Upgrades have gotten easier and to recommend that all are done in a test environment first seems excessive.
Post a Comment