Anti-Patterns in NAV Upgrade
See how (not) to mess up your Dynamics NAV upgrade, on-premises or in the cloud. With real-life examples – incidents we helped fix in PaaS. Warning: NAV partners, don’t do this at home (nor at work).
Context: when NAV is upgraded, developers have the chance to write upgrade code to move data across changing data structures. Writing good quality code will help successful upgrades.
General on upgrade
Problem: assuming that the upgrade table contains data.
If the table is empty, it means that either the upgrade has run, or there was no data in the original tenant; in both cases, the upgrade code should exit immediately.
Solution: if using an upgrade table, always validate that the table contains data before doing anything.
Upgrade code, can it be rerun safely?
Problem: if the upgrade code is not written in a way that makes it runnable twice (idempotent), then several failures can happen, including something as critical as data corruption.
In on-premises NAV installations, if something fails at upgrade, there is no way to run only the “remaining” tasks. You will need to run the whole upgrade again, and might end-up with data that you cannot trust.
What about the cloud? In Platform As A Service (PaaS), in some situations, the upgrade code needs to be run twice (for example, when moving tenants from a broken/frozen VM to a healthy one).
Read more on https://community.dynamics.com/nav/w/designpatterns/285.nav-upgrade
By Carlos Raul Garcia and Bogdana Botez at Microsoft Development Center Copenhagen
