GP 2016 R2 Upgrade Planning - Let's Get Started!

First things first, as always, run a test upgrade!! We are seeing cases for live upgrades opened up with potentially data-damaging upgrade problems, and we will always ask, "did you run into this problem during your test upgrade?" More often than we'd like to see, we get the response that they didn't run a test upgrade. Our response is "well, now this is your test upgrade."

The most common upgrade issue we see is that the database has a product installed to it, but that product isn't being brought forward in the upgrade. Alternatively, the product may have skipped the past few upgrade cycles, and is now on a non-upgradeable version. You can check on the versions of all your products by running a select statement in SQL against your db_upgrade table.

SELECT * FROM DYNAMICS..db_upgrade

This will list out all your databases and the products installed to them. What you'd be looking for is a product that is a full major version different than the other products. Then the question becomes whether or not you were planning on bringing that product forward. If not, make sure it's not in your SET file. If so, you will likely need to open a support case to reinitialize the entire module.

We are seeing a number of users upgrading from pre-2013R2 that are using the OLE Migration Wizard to attempt to migrate their OLE attachments to Document Attach objects. If you are considering this move in your upgrade, make sure and allocate time to test the migration wizard. Due to the extremely varied methods in which you could create a OLE attachment, the tool might not be able to extract your documents from the OLE containers. If the original objects were embedded instead of linked, we see better success with the embedded objects. Linked objects are more susceptible to failure with the tool. In these cases, the tool can't be modified to pull these data conditions, so these note objects may have to be manually re-attached in your environment.

Another thing to consider when moving forward is whether or not you are using Workflow on SharePoint, and want to use the new Workflow 2.0 functionality. There currently isn't any type of hierarchy transfer tool, so the new workflow will need to be set up for the company that is using Workflow 2.0. The logic and routing is different with 2.0, so make sure you allocate enough testing time to make certain that the new engine will work for your business needs. Don't forget to disable Workflow in SharePoint before upgrading your databases!

When upgrading major software versions, it's very common to upgrade hardware, switch to virtual, move to the cloud, etc.. When you move server infrastructure, virtualize your server, deploy TS or RDS in some way, you are changing the framework on which GP is running. There are some things that may never work the same in a virtual/remote deployment, that previously worked in the basic client/server environment. These core technologies have limitations just like GP, so something that GP might allow under certain environmental circumstances, might be crippled by an RDS limitation or a Remote App policy. Test, test, and then test again. Don't assume that it will "just work", no matter how simple the move to virtual or remote may seem.

Finally, keep your eyes on this blog as the new release drops, and customers start upgrading. Our team works incredibly hard at publishing news and information about any upgrade issues that start to become a pattern, and we will be using this blog just like before to alert to what (if any) "known issues" that we come across with the new version. Fixes, workarounds, and hotfix information is put out through these blogs, and the major issues make it into the Upgrade Hot Topic page.

Happy upgrades!