Despite what the salespeople will tell you, an upgrade is an intensive task. While it’s not as intensive as doing a new implementation, it should not be taken lightly by the partner or the end user.
One of the best things about Dynamics NAV/Navision it gives you the freedom to modify it so it fits your company like a glove. It’s because of this freedom, that you’re able to gain an competitive edge over your competitors and/or to satisfy your customer’s demands. With that freedom, you may have made a ton of modifications in order to satisfy a certain operation at some point in time.
As we all know in the world of business, everything is constantly changing. Requirements change, the way business is done change, the way we interact with each other change. Some change for the better, some may be worse. But one thing that is constant is that we, as human beings, cannot foresee the future changes with 100% certainty. Because of this, business owners and decision makers will often make modification requests that satisfies certain demands of their industry that seems brilliant at the time, but is quickly phased out in place of other changes.
The ERP software itself has to change with the business. This is why you’re considering a software upgrade to your business. Because business demands have changed and the technology has changed.
Having said that, there are basically 2 ways of doing an upgrade. In this post, I will explain the 2 methods of doing an upgrade and why I prefer one way over the other.
Merge Object Run Toolkit
One way to do an upgrade is the “merge object run toolkit” method. There are numerous tools to merge code, in fact, I’m surprised there’s not already a tool out there to automatically merge the code for you. Troubleshooting the error messages that comes up after compilation is easy. A programmer just have to compile, identify the problem, change the variables, remove some code, add some code, then done.
The merge object run toolkit option is quick, simple – a monkey can do it. In fact, if you were to go this route, I suggest you ask your solution provider to export all the codes into a text file, then hire an intern to do the code merge for you. Then ask your solution partner to toubleshoot errors that comes up. It’ll be a lot cheaper than asking your solution provider to hire an intern and bill you for it. If you don’t feel comfortable with an intern, you can contract an offshore developer for $10.00 to $15.00 an hour to do the merge for you.
The “merge object run toolkit” method is th the absolute wrong way to do an upgrade. Essentially, you’re piling on crap on top of crap. In this case, you’re better off NOT upgrading and staying with whatever version you’re using. It’ll save you a ton of headaches and unnecessary expenses.
Analysis of Objects then Upgrade
An upgrade has many benefits. They include newer technology so your workers can be more efficient, new ways of bringing information together at your finger tips, easier to get a new hire on board with easier interface. The additions are many.
However, one of the least looked at of the benefits of an upgrade is what we can take out. As stated before, because of Dynamics NAV/Navision ability to customize, you may have made some changes in your system that is no longer used or used sparingly. Removing unnecessary codes will simplify your processes, screen layouts, reduce training for new employees, and yes, improve the performance of your database.
In addition, there may be some changes or modifications done that is now part of the standard functionality in the new version. You may also want to consider removing those the modification in favor of the standard functionality to make support and future upgrades easier.
Doesn’t this seem like a lot of decision making for a “simple” upgrade that you may have been promised?
When doing an upgrade, assuming you have partnered with a good solution provider, should do analysis on existing modifications. List all important changes and modifications done to the existing database. Suggest what can be taken out and if the modifications have a standard function equivalent.
From the list, the users will need to decide what modifications can be removed, what to keep, whether to use existing functions, or revamp the existing process for a better process provided by the new system.
For the NAV partners, this requires a good knowledge of new features and how the new and existing functionalities are used.
Conclusion
Needless to say, I’m not a fan of of the first method. If you’re planning to upgrade using the “merge object run toolkit”, I would highly suggest you to save your money or donate that money to charity.
If you received a quote from a partner for an upgrade with the “merge object run toolkit” method, I would hang up the phone, burn the quote, and run as far away as possible. You may need to take a shower and change your phone number as well.
One of the NAV vendor told us that upgrading to NAV 2009 classic mode from NAV 4.02 is idiot-proof and we can implement it ourselves despite having heavy customization on our NAV 4.02. Because according to this vendor, NAV 2009 classic mode is 100% compatible with 4.02 and no further amendment is required. Is this true?
Maybe, maybe not. I would do the the executable upgrade in a dummy environment first to see if any problems arise. One note is that if you do the executable upgrade, you won’t be able to go back. Easily anyway…
Pingback: Properly Upgrading to New Versions of Dynamics NAV / Navision - Confessions of a Dynamics NAV / Navision Consultant