{"id":13245,"date":"2016-12-12T11:00:06","date_gmt":"2016-12-12T09:00:06","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/nav\/?p=13245"},"modified":"2024-04-02T16:16:43","modified_gmt":"2024-04-02T23:16:43","slug":"anti-patterns-in-nav-upgrade","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/dynamics-365\/blog\/it-professional\/2016\/12\/12\/anti-patterns-in-nav-upgrade\/","title":{"rendered":"Anti-Patterns in NAV Upgrade"},"content":{"rendered":"
\nSee 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).<\/p>\n
<\/p>\n
Context<\/strong>: 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.<\/p>\n <\/p>\n General on upgrade<\/strong><\/p>\n Problem: <\/strong>assuming that the upgrade table contains data.<\/p>\n 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.<\/p>\n Solution:<\/strong> if using an upgrade table, always validate that the table contains data before doing anything.<\/p>\n <\/strong><\/p>\n Upgrade code, can it be rerun safely?<\/strong><\/p>\n Problem<\/strong>: if the upgrade code is not written in a way that makes it runnable twice (idempotent<\/a><\/span>), then several failures can happen, including something as critical as data corruption.<\/p>\n In on-premises NAV installations, if something fails at upgrade, there is no way to run only the \u201cremaining\u201d tasks. You will need to run the whole upgrade again, and might end-up with data that you cannot trust.<\/p>\n 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).<\/p>\n <\/p>\n