Do you have a development environment for Microsoft Dynamics GP? If not, you need one.
In the early days of Microsoft Dynamics GP (formerly Great Plains), software updates were less frequent and relatively insignificant between major version releases, making it unnecessary for users to create a development environment. In the past, Microsoft’s development team would write the code to introduce new functionality to Dynamics GP, then defer the publication of that code until the next major release―sometimes as much as two or three years later.
Now, instead of making users wait for a major release to take advantage of these new features, Microsoft created a six-month cadence, whereby new functionality is released sooner than ever before. The first example of this accelerated release cycle began in March 2014 with the release of Dynamics GP 2013, Release 2. Known informally as R2, Microsoft revealed significant changes to tables and gave users more functionality without having to wait until the release of Dynamics GP 2015.
For many users, R2 updates are beneficial for their everyday tasks; however, when users apply R2 to their Dynamics GP software, it will complicate any third-party products offered by independent software vendors, as those will need updates too. This is where a development environment can come in handy―not only will users need to test the updates to Dynamics GP and how it will affect their processes, but they will also need to update and test their third-party software.
What Your Development Environment Should Look Like
The most effective way to test substantial software updates is by using a development environment. From a conceptual standpoint, there are two options for creating a development environment―a test company within the live environment or a separate standalone test environment. In order to properly prepare for the software changes Microsoft will release, creating a separate standalone test environment is more beneficial and necessary when testing Dynamics GP software updates.
Your development environment should look identical to your live environment―from your operating system to your version of Microsoft SQL to how much RAM is available on your server. Any and all system requirements and software in your live environment should be reproduced in your development environment.
Mimicking your current system will provide end-users with a representative environment for testing. Often, when a development environment is slow and difficult to work with, end-users will not get the most out of the testing phase or may even fail to complete it out of frustration.
How to Access Your Development Environment
To avoid conflict with your live environment, consider installing an application server in addition to the database server. As such, there should be two servers in your development environment―one that mimics the production database server in terms of the operating system and amount of RAM, and one that is simply the application server, which gives end users access to launch the applications for testing. End users can then access Dynamics GP on the application server via Remote Desktop and begin testing. You may want to consider giving your users alternate Dynamics GP passwords in the development environment so they consciously know when they are working in the development environment as opposed to the live environment.
Benefits of a Development Environment
The experience of testing before going live, in general, is a best practice―from trying a new process flow to troubleshooting. However, the biggest benefit is testing out those mission critical tasks that are unique and vital to your business, prior to rolling out in production. Once an upgrade is released into production, it’s difficult, if not impossible, to rollback if you missed something, which underscores the importance of having and thoroughly using a development environment.
Read More: Before the end of 2015, employers must make adjustments to how they record employee payroll and health benefits. For Microsoft Dynamics GP users, Microsoft is laying the groundwork to meet the mandatory Affordable Care Act reporting. Learn more in our blog post, How Microsoft Dynamics GP is Preparing Users for Affordable Care Act Reporting.