6 More Reasons You Should Consider Upgrading NAV

The Hidden Costs of NOT Upgrading NAV

1. Obsolete Technology– It gets harder and harder to bridge the gap between old technology and new technology the further upgrading is put off.

   Microsoft and Add-On Software vendors create upgrade tools that support upgrading from the current version to the new version. This is called an "Upgrade Path". Sometimes, this path will support previous versions, essentially skipping versions. However, every time an Upgrade is put off, waiting for the next upgrade, higher costs for the future upgrade is guaranteed. This is because the future upgrade path may essentially require the equivalent of multiple upgrades, i.e., to get from point A to point C, you need to get to point B first. Each path step (version upgrade) involves more layers of code changes that need to be factored into the upgrade costs.

2. Asset Overhead– Customizations are assets, value added features that satisfy a need by the client. The value of these assets was evaluated at the time the feature was requested, approved, and implemented. At the time, it seemed like an awesome feature, and, over time, it was forgotten or taken for granted and perhaps now seems like a standard feature of NAV itself. The value from the benefits of the feature continue on and have now fully covered the cost. However, customizations are not "do it and forget about it". Customizations are perpetually managed forever.

   Think of customizations as assets that require maintenance and care over time. They will forever be managed code. They will always be merged into new code during every upgrade. It can be a simple automated task, and usually is. However, old, obsolete, or incompatible code can be tricky to merge and add time to an upgrade. The code might even have to be refactored (re-written) to accommodate new technology, or a new customization, or a code change introduced by an upgrade, add-on or even a HotFix. During an upgrade, merging these customizations into Microsoft's new code, is a major part of the upgrade. In fact, if there were no customizations, an upgrade would be a trivial task; perhaps taking just a handful of hours, depending on training and server setup.

   The cost of an upgrade is largely dependent on how many customizations(assets) are involved. The cost to manage these assets will always be higher when upgrades are not done consistently. This is due to the Code Debt factor. In this sense, upgrading can be thought of literally as Asset Management.

3. Code Debt– Unnecessary costs associated with customizations can be mitigated by always upgrading to the latest version of NAV. I call these unnecessary costs, Code Debt.

   During the merge process, some code will merge automatically using various tools. However, some customized code requires developer interaction, sometimes re-writing the code. Some code becomes obsolete and is removed. Other times, it might be a customization for a feature that Microsoft has subsequently introduced in their base code. Either way, during the upgrade process, the code is somewhat cleaned up and likely in better shape for the next upgrade. It's much easier for a developer to refactor to code from a one-step upgrade path than it is to try and figure out how to merge code into a version that is two or more upgrade paths away – linear vs circuitous.

   Code Debt Example: Client is procrastinating an upgrade, yet wants some of the functionality of the new version. Somehow, the client talks a Solution Center into implementing a customization that does the same thing in their current (old) version of NAV. I call this the "Borrowing Forward" Anti-Pattern. When it comes time to upgrade, this will invariably create a data conversion task and a code re-factor. The “Borrowing Forward” anti-pattern will always add to Code Debt.

   The Upgrade is where the Code Debt interest comes due! Code Debt is perpetuated and compounded by Upgrade Procrastination. A good analogy would be Credit Cards that have zero percent interest for 12 months, then change to 35%. It would be wise to eliminate your debt before 12 months.

   There will always be a cost of managing your assets (Code), but the cost of your debt (Code Debt) can be zero with consistent and current upgrades.

4. Human Resource Atrophy– Users will use the technology given to them. They will get really good at using this technology, potentially to a flaw.

   Users could be happy with ancient technology, as long as they are comfortable using it, or they’ve been using it forever and they’re used to it. Meanwhile, their competition is moving on and running their businesses with the latest supportable, scalable, and superior technology. The user is missing out on technology that's full of new features and power and losing out on learning to use and talking about the new technology.

   A staff of users that are really good at the old stuff, but have no exposure to the new and/or current stuff are risking atrophy of certain parts of their brain, or entire parts of the staff. Sounds extreme. I believe it's true. Sadly, it will go unnoticed due to the rapid pace of technology in our society. The symptoms will be denial, frustration, apathy, and eventually, thoughts of an early retirement. (Side note: I've been known to exagerate to make a point.)

   Microsoft is constantly adding new features in NAV. Users that are on the most current version of NAV will be ahead of the curve with respect to the latest technology. Many of the most awesome features in the latest version of NAV contain usability functionality that users will find familiar in all user interfaces, including Web Browsers, Phone OS's, Mail App's, Music App's, etc. By perpetually procrastinating upgrades, users will be missing a cross platform training opportunity. What users are learning on their own by simply browsing the Web, organizing their pictures, or downloading music, can be applied to the latest NAV interface.

   NAV, up until the Role Tailored Client, was virtually unchanged from around the turn of the century until NAV 2009, when Microsoft introduced the RTC client. The old "Classic" client was admittedly out-of-date feeling, even in 2000. Nevertheless, it was much loved. It was great for data input, searching, viewing data, etc. It was a user's User Interface, built for user input and data analysis. Users got really good at using the Classic client.

   NAV didn't contain any significantly changed UI features until the RTC. So, with the introduction of the RTC, longtime NAV users were presented with a mind-blowing new interface built on XML(the Gold Standard for digital transactions and communications since the turn of the century). So, with the advent of RTC, NAV has somewhat caught up with the latest technology, finally.

   Transformation of customizations to the Role-Tailored Client really is like pounding a square peg into a round hole. It requires the developer tool equivalent of a chisel. Luckily, this is a one time task.

   RTC, behind the scenes, and the visible UI, is a paradigm shift from Classic. It’s not just a simple code merge, at least for Forms(to Pages), Dataports(to XMLPorts) and Reports(to RDL, RTC enabled reports). So, the “transformation” process is a big deal. There are tools that attempt to convert, but they fall short and require Developer interaction, usually manually re-writing a good bit of the customizations. The key here is that the customizations exist in these objects (some are custom objects themselves) and the Developer needs to duplicate or simulate the same behavior in the new object. This can be incredibly difficult, especially if the client has not upgraded since any version prior to NAV 2009. In fact, it can even be more difficult than the original request because the developer has no context for the customization. They only have the delta between the customized version and the old base NAV code. They can only base their new customization on that delta. So, getting to RTC is a major step and can be compounded when coming from an older version of NAV.

   That being said, development for Pages and Dataports is much simpler and, therefore, cheaper for the client in RTC, especially in NAV 2013. In fact, my prediction is that upgrades will also be cheaper going from any RTC to RTC upgrades. This, again, is because the RTC is such a paradigm shift from Classic. It literally brought NAV from 10+ years behind the times from a UI perspective, to current technology. We may never see such a drastic upgrade path again.

   Every day that goes by using the old Classic client adds to the stubbornness and resistance to change by the user. It's not about whether the user thinks "The old way works fine", "The new upgrade will not directly benefit us", "The new way is ridiculous", "If it's not broke, don't fix it.". It's about letting that attitude slip so far that it will get to the point where your upgrade path is three or five upgrades behind. Then, not only are the costs of upgrading exponentially higher with each step, but the user training experience will cause increased cost and undue stress for everyone during the transition.

   I make the point about Classic and RTC because I experienced similar attitudes and resistance to change when I was first implementing new clients to Navision 2.6 back in 2002. Users were used to their old system, AccPac, QuickBooks, Web based stuff. It really doesn’t matter. Trying to compare one system to another is like comparing an apple to an orange. The important thing is that NAV upgrades always are for the better. Really. You can argue all you want about what you like better about the old version, but the fact is, the cost of procrastinating will far outweigh the perceived value of the old version. And, that cost will continue to increase with every NAV version.

5. Support and Maintenance Cost– What is never talked about in upgrade cost discussions is how users will directly benefit from the latest enhancements to the Development Environment, Debugger, Code Designer, Report Capabilities, External Integration Tools, Data Access, etc.

   Why would anybody care about the Development Environment except the developer? Well, every issue resolution or customization will require the Development Designer. That is where the magic happens. Cost savings due to efficiencies in the latest designer are directly passed on to the client.

   The latest Development Designer allows the developer to perform complex coding tasks and issue analysis much faster than in previous versions of NAV, directly affecting the cost of every single issue analysis, resolution, and feature request. If the issue or feature is for an older version of NAV, any development, at the very least, perpetuates the old technology, adding to code debt and ultimately making it harder to upgrade. At worst, it technologically limits the development options and requires more work for the developer, adding cost to the client. Either way, this adds to a Code Debt snowball effect.

   If the client is on the latest NAV version, developers who are tasked with solving an issue or satisfying requests for a new feature are not constrained to the limits that are inherent in old technology.

   By making technological decisions based on the latest current NAV version, Code Debt is mitigated. Developing in the latest NAV version, it will be much more likely that code changes will adhere to the latest “best practices” and will more likely be automatically merged in the next upgrade, virtually guaranteeing zero percent interest on that code debt.

6. Finally and selfishly– developers simply like working in the latest development environment. So, make a developer (me) happy. Please upgrade!