Gradual Upgrade

(0) Share

Report

Posted on by Community Member

We have about 76 company databases that we will be upgrading from GP 10 SP5 to GP 2013. My question is, can we do this as a gradual process by standing up a new SQL instance and moving the databases over as we coordinate with the business.

*This post is locked for comments

I have the same question (0)

All responses (18)

Answers (1)

Richard Wheeler 75,850 Moderator on at

Like (0)

Report

How big are these databases? If you follow KB878449 you can get the new server set up with the logins and GP 2013. I would do a test upgrade on the databases and any modified forms and reports and then you will know how long it will take. Then you can schedule the production upgrade. It would not be advisable to upgrade the companies at different times. You could but then you have to have a third instance running and it gets very tricky.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks Richard. The last time we upgraded, it took a span of 5 days doing them one by one. The databases aren't overly large. Granted, we were doing this on a VM server so that may have contributed to the long processing time. We were fortunate the last time we upgraded that we had a 3 day window in the work week plus the weekend. We're not necessarily as fortunate this time around.

Coordinating with the business, we would move databases to GP2013, upgrade them and then remove access in the old GP 10 instance.

Is your recommendation on not upgrading the company databases in stages because of the chance of users making entries in the database before it's upgraded, or is it something more of having Dynamics with half baked databases that aren't upgraded.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks Richard. The Dynamics DB is 168 MB, company databases are no larger than 52 MB.

The last time we upgraded, it took a span of 5 days doing them one by one. The databases aren't overly large. Granted, we were doing this on a VM server so that may have contributed to the long processing time. We were fortunate the last time we upgraded that we had a 3 day window in the work week plus the weekend. We're not necessarily as fortunate this time around.

Coordinating with the business, we would move databases to GP2013, upgrade them and then remove access in the old GP 10 instance.

Is your recommendation on not upgrading the company databases in stages because of the chance of users making entries in the database before it's upgraded, or is it something more of having Dynamics with half baked databases that aren't upgraded.

Was this reply helpful? Yes No
Richard Wheeler 75,850 Moderator on at

Like (0)

Report

There are tables in the DYNAMICS database that track upgrades per company. It would be very difficult to upgrade the first 5, then the next 5 and so on.I started using SSD drives in my virtual server to speed up images. Given the total size of your databases that may not be practical. It is always best to just upgrade them all at once. If you can do it on a test image, so much the better. This way not only would you have good idea how long it will take but if any companies have upgrade issues.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I just wanted to confirm you indeed meant MB and not GB?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Scratch that, pulled the wrong column data. The Dyanmics DB is 700 MB. Most of the company databases are around 250 MB or less with about 20 or so of the larger ones being 800 MB to 1 GB.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Ug, I was afraid of that. Thanks

Was this reply helpful? Yes No
Richard Whaley 25,195 on at

Like (0)

Report

NOT recommended. The Dynamics DB maintains information on next note number, Smartlists, etc. If you convert some of your companies and not others, when you convert the others, the Dynamics db from the first conversion is not updated with changes from the Dynamics DB from the v10 instance.

Sorry, I would NOT split the update. (You will also get issues with the dbVersion table......NO)

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

We have about 100 companies and also experienced long upgrade times. I recommend you do a complete test upgrade and look at the database sizes after the upgrade is complete. If the live databases are increased in size enough to handle the upgrade before pushing the button then the upgrade runs much faster. I think much of the time involved is the server expanding the database size in pieces as the upgrade progresses. After we expanded the databases then we used a priority order for the companies upgrading the ones used most often first and the ones used least often near the end. As long as the intercompany entries are restricted to completed companies people can work in a company that has completed the upgrade process even while other companies are still being upgraded if that becomes absolutely necessary.

Keith McConnell

Was this reply helpful? Yes No
L Vail 65,271 on at

Like (0)

Report

Keith,

I have used this method as well. Expanding the databases is absolutely the way to go - it made a huge difference. I ran into trouble when the current installation was on an incompatible build for the upgrade. I had to upgrade all of the companies to a compatible build and then went ahead with the final upgrade prioritizing the companies.

Kind regards,

Leslie

Was this reply helpful? Yes No