I was asked by the chairman of another partner today – how automatic can we make upgrading Dynamics NAV? Specifically, he wanted to know, how realistic was it for him to ask his developers to upgrade his clients within six months of a release by Microsoft?
By posting a reply on here I’m aware of the NoSuite trolls who would love to hear that upgrading NAV is weeks of work for everyone. Happily for me, the actual reality is not what they want to read.
Scripts make it easy with the right coding patterns
If you do your Dynamics NAV customisation in the right way, following the correct design patterns, then upgrading through either the monthly cumulative update or a full release, is a matter of running the scripts. That’s means it’s no more than a few minute’s work.
By comparing the objects you have in your live system with Microsoft’s untouched virgin objects from the exact same version, you can produce first a ‘delta’ of any changes that have been made to those objects.
You then apply that delta to the new set of objects which produces the same changes in the new version. Voila – you’re ready to go!
Events and Extensions make it a none issue
Oh and that’s before you factor in 2016’s new extensions and events. If you use those you will not have to modify the standard objects at all and that means not even the script process is required.
Having had some time since the most recent release of NAV, and had projects go live on 2016 now, we have practical experience of these and even with this first release of the extensions and events its surprising what you can create using it. Events allow lots of zero impact changes to core functions once you have gotten your head around them. This is something your developers need to adapt now if you’re not to incur even more technical debt in the future.
Is it really that simple? Well you can get exceptions during the scripting process when applying the delta’s if the system cannot work out where to reinsert those changes in the new objects. Typically, this happens if either Microsoft have changed the exact same code (something you will want to know about) or you have not done your customisations in a place or way that’s easy to ‘merge’.
Older upgraded code can give exceptions – consider redevelopment sooner rather than later
This means that the exceptions we get are from customisations that have been done many years ago, before the best practise around this was established. Technical debt, I guess, from having a system that’s twenty years old now. That’s a heritage and maturity that solutions like NoSuite can only dream of. I’ll also wager they will have their own issues with this before their system is too much older or supporting all that legacy technology will make them slow, uncompetitive and stifle innovation.
Any recent development done in the last few years should be fine, although its good practise to run it through a scripted delta comparison as part of testing the development prior to acceptance into your live solution. If it fails for any reason, changes can be made before its live – always a better process. If it repeatedly fails to merge, then that’s down to the quality of your developer and they should do the corrective work for free!
For customisations created from before 2013 and just upgraded ‘as is‘, consider paying to have them reworked, I know it’s hard to justify money to make the software just do what it already does but it will pay off in the long run.
Make sure your ISV add-ons are script upgradable
One final point – for any ISV your considering making part of your solution, are their changes ‘script mergeable? – if not I’d advise you either don’t use or find a different one.
