By Steve Endow
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?
![]()
![]()
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?
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.
