September 18, 2019
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 UpdateInstalling a cumulative update can be disruptive to your business if not properly planned. There are many things to consider:
Code FreezeA 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.
TimingTreat 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.).
Database EnvironmentArcherPoint 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
Testing and DeploymentThe 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 ProductionAs 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.
- Login Error: Communication protocol mismatch between client and server
- Creating a Date Table in Power BI
- How to Make Measures Total Correctly in Power BI Tables
- The Microsoft Technology Stack – What It Is and Why You Should Care
- The Top Eight KPIs Retailers Should Be Tracking (with Formulas) for Your Retail KPI Dashboard