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, 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 the company databases. The timing for this depends on several factors including the size & number of company databases + the capabilities of the hardware the process is running on. To a certain extent, the number of modules present in the environment may also factor in.

When I call this "core" GP, I am referring to the modules that are included 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 SQL, 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 that all modified dictionaries in use are accounted for 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 through the ISV products that are utilized. 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 a user launches Dynamics GP to trigger the opening of a window to kick off required procedures and/or table updates.

The timing for this will vary depending on how many ISV products are used 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 take 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", and 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 installation 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 there may be 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 the 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

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 tend to have a fairly broad definition of customizations but for this post, I think it's safe to say upgrading customizations 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 the 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 to do validation testing on the core upgrade.

Context

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, and 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 middle-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!