From the Newsgroups: Upgrading 150+ company databases

This week the partner newsgroup takes on the topic of upgrades and you will be surprise to know the different approaches available to do upgrades for large amounts of company databases, especially when down time is not much of an option.

Q: Have got a situation with a client with 150+ companies (databases) on version 9. Client is extememly downtime sensitive. Is there a supported upgrade technique or method to minimized downtime?

The answer comes courtesy of Microsoft's Randal Mayer, Partner Technical Online Community moderator.


A: The supported approach is to prioritize the databases by urgency and importance of being completed. It is the high priority databases which will require being upgraded first, validated, backed up and then released to production. For the remaining databases of less importance and less urgency, run Utilities to convert them afterwards ideally after hours.

NOTE: All company databases are not required to be upgraded. In other words, once the system database DYNAMICS and a company database are upgraded, users having the new GP client can access GP to view the upgraded company data.

Dynamics GP Utilities by design does not allow an in-place upgrade of a database to run while users are in that database. In order to upgrade a database, a lock is placed on the database (duLCK table) to ensure users cannot access it from within Dynamics GP.

As you know, once the system DYNAMICS database is upgraded, no user will be able to access Dynamics GP unless using a GP install at the new version.

Not found in a manual but known to be occurring, you can also run Dynamics GP Utilities from multiple GP installs. The risk is of an interruption or resource issue at the SQL Server machine. If SQL Server machine has the resources and ideally designated strictly for SQL Server, multiple clients running GP Utilities can be converting company databases. I find this batch type approach where high priority companies are upgraded via GP Utilities at the SQL Server and lower priority companies from a client or two machine.

There are other approaches like upgrading databases amongst multiple SQL Server instances then restoring plus others. To stay within a supported approach as you request, I will stop here with the above information.

It is becoming not all that uncommon to find 100+ database GP installations. In summary, prioritize the databases during your upgrade planning.


I hope this information is useful and that it will help you when planning your next upgrade.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Comments

Perry Smith said…
Mario,

I have upgrade many customers with 125+ db's. Max was 225 db's. I have been using the multiple workstation method exclusively with fantastic results. With a high powered server, 225 db's were complete in 1 weekend.

Much better than the 1-2 weeks it took previously.

Perry Smith
GPITConsultant@gmail.com
Perry Smith said…
Sorry, I meant Mariano.
Mariano Gomez said…
Perry,

Much thanks for the insight into your company's upgrade and definitely a good approach.

MG.-
Mariano Gomez, MVP
Perry Smith said…
Mariano,

1 more thing that I discovered. When I 1st tested using multiple workstations to run an upgrade the point of diminishing returns was 6 companies at a time. It started taking a longer total time to complete the upgrade when I used more than 6 workstations. It has been a few years since the last upgrades, but I am sure with faster servers you can utilize more workstations.

Perry

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

eConnect Integration Service for Microsoft Dynamics GP 2010