GP Upgrades - series wrap-up

Well, it’s finally the end of the series and this one is a short-ish one where I review some last minute tips.

Posts in the series

  1. Series intro
  2. Process overview
  3. Know your environment (part 1)
  4. Know your environment (part 2)
  5. Know your environment (part 3)
  6. Know your environment (part 4)
  7. Know your environment (part 5)
  8. Know your environment (wrap-up)
  9. Testing

Random tips!

As I wrap up this series, it’s time for the more random things that don’t fit nicely anywhere else.

Log in as regular users and use “regular” workstations

I’ve seen a few situations where all the testing for an upgrade was done on the new server with users logged in as administrator. Unless the users are typically running GP on a server day to day (which is unlikely!), the proper way to test the GP “client” is by using GP on a workstation or terminal server similar to what they use day to day. What you want to prevent here is permissions issues that aren’t apparent until go live. If users test on a server, or use logins that have more permissions than they have on their own workstations, you may find permissions issues at go live. This is particularly relevant if there are firewalls on your servers.

Related to the above is on the installation side: install the new version of GP on a regular workstation, if GP will be installed on workstations at go live (or install on a terminal server if that’s what users typically use). Workstations introduce a basic “server-client” relationship where things like firewalls and permissions will be tested immediately upon logging in.

Change company names for testing

My “pro tip” is in the test environment, change the company names to add “upgrade test” or something like that to the company names. So much of testing involves printing out reports or forms, most of which contain the company name. It’s not unheard of to find users confused over which report is from test and which is from production, or worse, trying to guess based on the date/time stamp on the report because the rest of the data on the report looks identical.

Change logos for testing

Where you are able to, if there are logos or colour schemes for web applications, try to change the logos so that the login pages or backgrounds clearly indicate it’s a test site. If the user can’t tell if they are in “live” or “test”, mistakes can happen!

Test the basic stuff first, not the custom stuff

If you are starting to test while the technical team is still upgrading or updating other components of the environment (like external applications), make sure the users know what is ready to test and what is not. If customizations need to be upgrade, testing items that touch those areas should be scheduled accordingly so there is no time wasted trying something that won’t work properly. Get the basic stuff out of the way early!

Test connectivity early

The last tip is a tiny bit contradictory to what I said above, however, it’s not intended to be. When you are dealing with lots of moving parts outside of GP, some of the more basic tests can be very simply “does the application launch?” kinds of tests. If I’m not doing the technical work myself, once the environment is ready, I’m often launching the various apps just to make sure I can connect. I’m not testing them all on day 1 though, just checking my inventory so-to-speak to ensure all the things I’m expecting to be there are there and function at the most basic level without errors.

Go Live checklist

As you run through testing, you will likely run into issues. Most typically are pretty minor, some may not be. What I want to ensure I am tracking are (a) tracking the issues we ran into and (b) how they were resolved. The other thing I do is evaluate if that issue will re-occur at go live or not.

Some things you can address during testing and ‘save’ to be re-used at go live. If there are issues with any modified reports or forms, typically you make the necessary changes in testing, set aside the dictionaries and at go live you’re ready to copy them into the new production environment. That is work that doesn’t need to be repeated. On the other hand, part of many upgrades are new features and new windows or forms that need to be assigned in user security. Those things you cannot do in advance but you can make the changes in testing, print out the roles, tasks or user security changed and use that to redo the same changes after go live.

Whatever it is, it’s important to note that on a go live checklist as a reminder/to-do list for things that need addressing outside of the obvious technical upgrade steps themselves. If you’re not sure, having the issues documented that you ran into and how you resolved them will go a long way in helping you through go live issues.


This concludes my series on upgrades with Dynamics GP. There are many other areas I could have dug deeper into, but I hope this series is of use to those of you tasked with understanding what the pitfalls may be and what to consider before you start.

We have reached the point in the product lifecycle where there are fewer “major” upgrades for customers on the 18.x series of product releases, which is great. I’m enjoying the 18.x annual “updates” which makes keeping a customer site up to date pretty painless.

comments powered by Disqus
Built with Hugo
Theme Stack designed by Jimmy