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 an 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 is important 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 workstations, they may find permissions issues at go live. This is particularly relevant if there are firewalls on the servers that may differ from firewalls on the workstations.

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 the test environment 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

If there are logos or colour schemes for web applications, try to change the logos so that the login pages or backgrounds 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

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 upgraded, 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 dealing with lots of moving parts outside of GP, some of the more basic tests can be "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

While running through testing, issues are going to appear. 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 can be addressed during testing and 'saved' to be re-used at go live. If there are issues with any modified reports or forms, typically I would make the necessary changes in testing, set aside the dictionaries and at go live I'm 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 cannot be done in advance of the actual upgrade but make the necessary changes in testing, print out the roles, tasks or user security settings that were changed and use those reports to redo the same changes after going 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. Having the issues documented that users ran into and how go-live resolved them will go a long way in helping the organization through go live issues.

Summary

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 helps someone understand what the pitfalls might be ahead of them and what to consider before starting.

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.