I'm finally ready to get back into a regular blogging rhythm and will be starting a series around Dynamics GP upgrades. I've presented on this topic a few times and what I plan on covering is how I approach and manage upgrades. What this series will not be about is the technical "how to upgrade" aspects. There are plenty of other articles out there covering the actual upgrade process and technical elements, so I don't feel the need to repeat that here.

I am working with a client on their upgrade now so a lot of the things I cover will be fresh in my mind as they are in the "test upgrade" phase right now, and not "going live" for a few more weeks now. This also may result in the topics being a little bit random, vs. a specific order of events style of posting!

Versions & product lifecycle

One quick sidebar on Dynamics GP versions and the product lifecycle: the current product lifecycle page has information up to the year 2024, with TBA (to be announced) after that. This lifecycle page hasn't been updated since Sept 2019 so I wouldn't be surprised if it gets updated in the coming weeks or months as Dynamics GP 2016 is reaching its end of support date.

Those who are currently planning on upgrading to GP 18.x, that is what I refer to as the last "major" upgrade for Dynamics GP. Starting with the October 2019 build, each change after is still an 18.x build which means environments can be "updated" annually to keep current on the latest version without a significant project to make that happen. For most clients, applying the updates annually, even with partner support, will be far less costly than the once-every-few-years big upgrade project. The key phrase there is incremental 18.x builds are updates, not upgrades.

I plan to cover upgrade tips for as long as I can think of tips to share. Once most clients are on an 18.x build, a lot of what I will cover may not be relevant anymore, as updating annually typically won't require the same formal process and testing.

Tip #1 - always do a test upgrade

The first "tip" is simple: when moving between major versions (from GP 2015 or GP 2016 to GP 18.x for example), always plan on doing a test upgrade. There are clients out there with very simple "vanilla" installs, few-to-none on the ISV products side of things and those could be an exception to the rule, but my advice remains the same for everyone: set up an environment where it can be run through the upgrade process once before a live upgrade.

Why? I've got several reasons, and here are a few of them:

  • The upgrade process itself is then tested, to ensure whoever is doing the upgrade is installing the right products and modules, in the right order, and documenting any issues as they arise. This is even more important for customers doing their own upgrades, that aren't doing this type of work every day, day in, day out.
  • If there are issues, there is a window of time to investigate and resolve them. If deciding to just upgrade without testing first, often that means after hours or on a weekend when support options are more limited.
  • If there are new features users are interested in reviewing, a test environment gives them a place to kick the tires without committing to live configuration changes.

That's it for this intro post… stay tuned for more in the coming weeks.