GP Upgrades – process overview

Last week I posted the first in a series I am writing relating to Dynamics GP upgrades. This week’s topic is an overview of what the process looks like for many organizations, from the point of view of upgrades I’ve done or been involved with. At the end of this post I’ve included a Context section to further clarify what my background is which will heavily shape the recommendations and approaches I discuss through this entire series.

Typical Process

Understanding the overall process is helpful for users not familiar with it, in order to plan the activities around the upgrade. While I don’t intend to delve into the actual technical details of the steps in this process, I feel it’s important to understand at a conversational level what occurs.

What I describe below are what I consider the core steps from the point of starting to install the new versions of the applications and users starting testing (or using) the new version. Note: there are many details I am intentionally omitting here. 🙂

Dynamics GP “core” upgrade

The guts of the upgrade is the upgrade to Dynamics GP itself – the system database (DYNAMICS or otherwise) + each of your company databases. The timing for this depends on a number of factors like the size & number of companies you have + the capabilities of the hardware the process is running on. To a certain extent, the number of modules you have in use may also factor in.

When I called this “core” GP, I am referring to the modules that are including in the installation of the Dynamics GP application itself, from Microsoft. Core could include “extra” modules like Human Resources, Fixed Assets, Canadian Payroll, SafePay, Electronic Bank Rec etc.

After installing the new version of Dynamics GP, GP Utilities will be used to verify the module/application versions and then the updating of the SQL components from old to new. The “chug time” as I refer to it can be quite long – hours of watching it progress through the updates one company at a time. The processes historically are not efficient from the point of view of a SQL side of things, i.e. if there are table changes, the process still (I believe) copies data out to a temp location, drops the table and recreates the table and repopulates the data, vs. more efficient ways to alter tables in SQL that may not take as long.

Modified dictionaries

This isn’t necessarily the “2nd” step but often it’s done right after the core GP upgrade is complete. Any modified forms and reports dictionaries need to be upgraded, and that process is also run through GP Utilities. The complication in this particular step is ensuring you have found all modified dictionaries in use as not all clients utilize the “shared” dictionary approach. I’ll talk more about this when I get into a “know your environment” section later in the series.

In the last few versions of Dynamics GP, I’ve found very few issues with reports dictionary upgrades, i.e. rarely are there issues to be corrected. I don’t have a lot of recent experience with clients heavily using modified forms so I can’t comment on that. If there are significant forms and/or VBA involved, this often falls under the category of “Customizations” which I refer to below.

Third Party (ISV) products (within the GP application)

Once core Dynamics GP has been updated, the next step is typically to work your way through the ISV products that you utilize. In general, although this may vary widely, the process would be installing the new version, and running through whatever upgrade process they identify in their documentation. Many ISV products have version checks when you launch Dynamics GP to trigger the opening of a window to kick off required procedure and/or table updates.

The timing for this will vary depending on how many ISV products you are using and the nature of the products. Some products are significant in size & how they integrate with GP (like Key2Act Signature products) and may take more time to update than others. Products that have significant data – transactional products for example – will often taken longer to update than, say, a reporting tool like “Smartlist Builder” might take to update.

External Microsoft or ISV products

At this point in most upgrades, Dynamics GP may be back up and “functional”, ready for testing (or going live) but there may be additional products utilized outside of the GP application that need upgrading. These can range from standard applications such as Integration Manager and Management Reporter from Microsoft themselves, or any of a variety of applications from other ISV partners. Many clients will have external reporting or integration tools and/or other products interacting with Dynamics GP from outside of the GP application (like A/P automation applications for example).

For reporting or integration tools, the install of the application isn’t usually the hard part, it’s the reviewing of the reports and integrations themselves which trigger upgrade work. Each tool is different in how they interact with Dynamics GP or the underlying SQL data so you may have a lot of work to do or none.

External products do not always need to be upgraded to be compatible with multiple versions of Dynamics GP. I’m working on an upgrade right now at a client where they utilize a few “external” applications and only 1 of them is being upgraded. Even if a version isn’t changing, if your situation is a “test upgrade”, those external apps still often need to be installed in the test environment so that they can be tested and that still takes time to complete.


Customizations are the wildcard in this post. There are so many different definitions of what a customization could be in the first place that it’s hard to give a blanket statement on what an upgrade process looks like. I, personally, tend to have a fairly broad definition of customizations but for the purposes of this post, I think it’s safe to say upgrading a customization will either be done after the core parts of the upgrade have occurred OR it may be significant enough that it’s a specific part of the project scope with your consultant/partner. Most times I find it fits in between those two. There is no way to give a rule of thumb on timelines for upgrading customizations.

When I have been involved in client upgrades with anything “significant”, all work around that was after we got the users at the client in doing validation testing on the core upgrade.


For this particular post, the context may be important as there are going to be multiple views of what the process looks like. Historically, my experience with upgrades has been with clients who are mid-range complexity and size – multiple Dynamics GP companies, multiple users (10-30 most commonly), multiple ISV products, minor customizations if any. What I describe above may seem overly formal for the client install that has few-to-none on the ISV module side of things and a simple 1-2 company environment with few users. On the other hand, there is also significantly more to plan for when it comes to the larger environments – dozens of companies, multiple ISV products, medium or greater customizations in place etc.

For most of the series, what I am talking about are that middle ground sized clients as that is the background that I have worked with the most over the 20+ years I’ve been working with Dynamics GP!

2 thoughts on “GP Upgrades – process overview

  1. Reply
    Mike Peck - May 27, 2021

    I am planning an update (I believe, if I understand your first entry in this series correctly) from GP2018 R2 for the January 2021 release. Am I saying that correctly?

    If so, are you saying the ISV products need less attention than they needed when a Upgrade is being performed or merely a different approach to updating those applications.

    1. Jen Kuntz - May 27, 2021

      Hi Mike,

      Thanks for the comment.

      Part 1 of your question, yes, if you’re already on 18.x moving to a newer release of 18.x, to me that is an “update” not “upgrade” but others may disagree with me.

      Part 2 ISV products: I wouldn’t say they need less attention, no. Depending on the ISV products you are using, some also need updating with every update you perform on Dynamics GP, some may not. Sometimes there are updates to Dynamics GP that aren’t compatible with the ISV product without also updating it, it’s hard to generalize there because the types of changes to GP vary. The approach to update ISVs will always be different, each ISV product has their own update process. The best way to confirm compatibility is to check the websites of the ISV products you use and/or check with your consultant or partner (if you are a customer). MOST of their websites will list compatibility or “tested with” and a GP build number so there’s no confusion over what works with what.

      One example since I’ve been picking on SmartList Designer: eOne’s Smartlist Builder page shows a new build of SLB for each 18.x release (18, 18.2, 18.3) so you would update that when you update GP.

      I hope that helps?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to top