Dynamics NAV Cumulative Updates Part 2: Planning
What do jeans craftily turned into bell-bottoms have in common with Microsoft Dynamics NAV? In this blog series, we discuss how cumulative updates are like the pieces of fabric used to transform straight legs into bell bottoms: They take what you have and make it better, newer, and up to date with the latest developments in technology. Part 1, What You Need to Know, lays the groundwork by reviewing the basics about cumulative updates. In this blog, we discuss planning.
Planning for a Cumulative Update
Installing a cumulative update can be disruptive to your business if not properly planned. There are many things to consider:
A code freeze means that no new changes can be started or introduced to the code while you’re working with the cumulative update changes, testing them, and finally, deploying them to your production environment. Therefore, any ongoing work you have in development or test will need to be completed and moved to production to get it out of the way.
Treat your cumulative update as a project. If you know you have an audit, a business change, or a vacation season that will reduce the availability of your staff for a period, you probably want to pick another time for your update. The average cumulative update can take a 5-10 days to deploy, 3 weeks of rigorous testing, and another day or two to deploy (Different databases provide different levels of complexity through ISV code, custom code changes, external interfaces, etc.).
ArcherPoint recommends a three-database environment for all our clients. This consists of:
- A development environment for the use of developers in creating and coding solutions
- A test environment for testing those solutions with data resembling that of the production environment
- A production environment – your live business
This is critical to the success of any project. The cumulative update will need to begin on a synchronized set of objects, meaning that what is in production is also in test and development. That sometimes will require an object sync, which is the process of identifying (by code compare) the differences in code from one database to another. If you’ve been diligent about deploying objects in the correct way (never directly to production or test), then this won’t be an issue. Yet, it should always be tested. Otherwise, you run the risk of overwriting any changes or fixes that are not in development.
Depending on the version you are working with, you might be required to set up a local install of the new version (executables and all) to pull out the objects to be merged in txt format. I’ve seen a NAV 2018 version that did not respond well to the export to text function when placed in an older NAV 2018 executable version. An error stating, “The type ‘5056’ was not defined for the function” was received.
Testing and Deployment
The cumulative update, like any code change, will first be applied to DEV, and then moved to TEST. When in test, a full regression testing is needed. It is recommended that at this time the production database backup be used to create a fresh test database, providing your most recent data. For regression testing, you want to test all activities you do in your live database to be sure you get the same results with no funny stuff (changes in data, errors thrown, etc.).
Once the code has passed regression testing by all departments, and all departments sign off on their testing, developers can then move the code set into production. At that time, if you’re also installing the executables, you can put those in place as well (You cannot, however, put them in place before the code change).
Creating a Test Database from Production
As a reminder, your production database reaches out to the world through EDI, credit card transaction, emails to your customers, your web store, and so on. When restoring a production database for testing, be sure you disable all these external connections. Otherwise, you just might send all the invoices you sent your customers yesterday by email, again today (memories…like the corners of my mind!).
In the next blog in this series, I’ll give you some hints for developers who are assigned to apply the cumulative update to your code. It doesn’t have to be painful, so let’s make sure it isn’t.
Contact ArcherPoint with questions or needs around planning for your next update.