Dynamics 365 F&O/AX Dynamics 365 CE / CRM Dynamics GP Business Central / NAV UG Dynamics SL Power Platform Fabric UG MS Copilot UG

[David Morinello]

I have a question on a GP upgrade trick I’ve heard of, but never tried myself.

We are about to make the jump from GP 2013 to GP 2016 to GP 2018 R2.

A few of our GP 2013 Companies are static at the moment. One is a Professional Advantage Archiver historical database.

Does anyone have a Well-Defined Procedure to load (restore) the Pre-Upgraded company backups after the other GP companies go through the multi-hop process?

1. When I do the Production upgrade through the whole double-hop process, I would like to unselect the 3 static companies. Skip upgrading them from GP 2013 or GP 2016.
2. Instead I would restore the already upgraded 2018 R2 database copies and have them in place once the others are upgraded to GP 2018 R2..
3. Is there a script somewhere that would tell GP this was upgraded already? I assume updating the DU Tables?
4. Or maybe the GP 2018 Utilities might make a pass though the data and recognize it was already current?

If I can do this I could shave several hours off the upgrade when we do this in production.

——————————
David Morinello
Senior Developer
TruckPro LLC
Cordova TN
——————————

[Ven Sharma]

David 

I have taken this approach before, GP 2010 SP2 to GP2018R2. I wish I had a neat step-by-step outline of that approach.

Are you also moving the databases from SQL server A to SQL Server B? 
In our case, we did get a new SQL server.

We identified a flight of companies that would be upgraded first (in production), say Wednesday of a given week (marked them as read-only once upgraded in both places).
The remaining companies were upgraded over the weekend and users were allowed to access the production system Monday morning.

The key cons with this approach Users can’t get to the earlier flight of companies and add JEs or such,
And between the Wednesday and go-live any system level changes done will have to be repeated in production.

Best of luck, I am excited for you as I went through a similar multiple hop upgrade myself a few years ago.

Best

——————————
Dynamics GP Credentialed Pro (Install)
Ven Sharma
Finance and Admin Systems, Administration
American Public University System (APUS)
Charles Town WV
——————————
——————————————-

[Jeff Woodard]

I’ve tried to do this a couple of times, but found out that some third party products and even some core modules store their db level information in tables other than the DU tables in the Dynamics database, and the time spent tracking the data quickly outweighed the time churning through the upgrade. The Minor release levels become very difficult to manage based on which service pack or release or hotfix you’re using.  Unfortunately, a double-hop means that you’re going to have to go through at least the first full upgrade on the 2013-2016 before you can restore the 2018R2 version.

We have a test company for each of our 10+ core companies, and I will routinely do a first pass to upgrade only the production companies, Then I restore the upgraded company databases to the test companies, and repeat the upgrade to select only the test companies. With the single-hop upgrade, the upgrade code seems to treat the restored test companies as a previously failed upgrade attempt, and the upgrade time (as a guess, I never officially logged it) 50-75% of the time it takes to do the full upgrade. The bulk of the SQL work has already been done – it executes the standard upgrade code to update all the versioning tables correctly, but essentially has ‘0’ rows to update in the production data, so runs a little faster.

If you have a very limited number of core modules in your static companies, you might try restoring the 2018 company db to the 2016 instance upgrade, but not sure the time savings would justify the effort if you have to re-run the upgrade if it fails anyway.

——————————
Jeff Woodard
Chief Technical Officer
Transportation Financial Services, Inc.
West Palm Beach FL
——————————
——————————————-

[Donny Kensmoe]

I have done hundreds of GP upgrades over the last 16 years and have often wondered about what you are proposing but never had the guts to try it.  But I would imagine you could re-engineer the scripts in this case to set the version numbers to the future version rather than the old version. 
https://docs.microsoft.com/en-GB/troubleshoot/dynamics/gp/restart-the-upgrade-a-company-database

——————————
Donny Kensmoe
Senior Consultant
Wipfli
Green Bay WI
——————————
——————————————-

[David Musgrave]

Hi David

I would recommend upgrading all companies in a test environment.

Then if you are 200% sure a company has not been updated in live, you can backup and restore the already upgraded company from the test environment when you do the live upgrade.

Regards

David

——————————
David Musgrave MVP, GPUG All-Star

Managing Director
Winthrop Development Consultants

Perth, Western Australia

http://www.winthropdc.com
——————————
——————————————-

[David Morinello]

On a test server I have already completed a full GP 2013 (1538) to patch 2230, to GP 2016 (716), to GP 2018 R2 (727)  GP Upgrade. Full SQL backups were made after each step. Collections Manager, Archiver, SmartList Builder, and SmartView are current to 2018 versions. I am 100% certain that the archived company will not change. I have created a 140 page runbook to document the full upgrade steps. I have had my GP Upgrade Duration Script.sql capture the DU major & minor version information and the length of time spent for each portion of the upgrade.

Shaving 4+ hours off of a Production rollout is a useful goal

db_name	GP 2013 Patch 2230 Duration	GP 2016 Duration	GP 2018 R2 Duration			GP2018 R2 DB Size
ArchiverDB	0:13:00	2:16:14	1:52:36			691,626
	4:21:50

I strongly suspect that since my backed up GP 2018 companies are fully functional, any potential db level information stored in the Archiver company db would survive.

I will confirm this Theory with the Test environment.
My theory is that if I restore the GP 2018 SQL backup of that one company database before starting the upgrade at GP 2013, then manipulating the DU tables accordingly, I should be able to fool GP Utilities.

1. First into thinking that the Archiver company db is already at the 2230 level, (The green checkmark)
2. Then at the GP 2016 716 level,
3. Then at the GP 2018 727 level.

Can I fool Utilities into thinking a company is already upgrade. Will GP Utilities skip touching that company if already “Upgraded”?
The goal is to skip entirely the hours long upgrade durations.

I still need to figure out if only the DU000020 table needs updating, or if it is both DU000020 and DB_Upgrade tables?
Could this be as simple as 3 simple SQL scripts, one at each of my hops?

——————————
David Morinello
Senior Developer
TruckPro LLC
Cordova TN
——————————
——————————————-

[David Musgrave]

Yes David.

I would say that restoring the already upgrade company and updating DU00020 and DB_Upgrade tables to match will be all that is needed.

Regards

David

——————————
David Musgrave MVP, GPUG All-Star

Managing Director
Winthrop Development Consultants

Perth, Western Australia

http://www.winthropdc.com
——————————
——————————————-

[Thaddeus Suter]

In addition to the two key tables (DU000020 and DB_Upgrade) that  David mentioned I would take a look in a couple more as well:

TA00860

PA00020

APR000020

SYICMR01

all DYNAMICS

Now related to the issue, we also have a number of GP databases on the production SQL Server that are retired from day to day operations. When that occurs we now migrate them to be a Company under DYNAMICS2 leaving the operating production companies under DYNAMICS. At this point, there are more companies under DYNAMICS2 than DYNAMICS but this approach gives us two separate GP updates to run. We update the DYNAMICS2 companies usually first and then the DYNAMICS companies. These separate updates can be done days or weeks apart and user access is managed through different published Apps in different RDWeb Servers or XenApp as the case may be.

——————————
Thaddeus Suter
Retus, Inc
HELOTES TX
——————————
——————————————-