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 ToolkitOne 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 too. 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 UpgradeAn 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.
ConclusionNeedlesstosay, 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.
I agree completely. Actually as I see it, then upgrades is almost a science in itself. Not something which should be left to newbies or interns - unless you of course just transfers all the changes. But then again nothing is really gained by upgrading.
In fact I often recommend companies who have been running Navision for 5-7 years that when they upgrade, they should consider scrapping all their old modifications. We then keep it as an unmodified version until we after the test data upgrade, starts bringing in the users. This way we only upgrade the functions and features which are really needed in todays business. This way is of course not always possible, but when it is, then it's a great way.
But surely the Analysis and then Upgrade way is in my eyes the only way.
I just had a client who asked me, another Danish partner and an Indian offshore company for a quote for the upgrade. The Danish partner and I quoted approx. the same - well mine was actually about 20% lower as I had already been doing a 2 hour pre-analysis together with the client and knew what not to include. The offshore company quoted 400% more hours than me, but based on your first mentioned method!
Luckily the client understood the value of doing a "real upgrade".
Additionally I would recommend that every client keeps a "System Log Book" where all changes are document, and especially the reason for the change and who requested it. This way the upgrade will become much easier to do next time the client needs to upgrade, as it is very fast to find out which changes can be scrapped.
Thank you! =D
I think it's the "promise of a better life" that prompts companies to blindly upgrade to a newer version.
If a person's life is already messed up, buying and moving to a new house won't make it better.
Great post Alex. Its one of those things I read and think. Do people really do this? Then you see all the offshore upgrade centers out there, and you realize that yes its what happens.
Its totally pointless to simply take all your existing code changes and move them to the latest version. The only reason to do that is because you have some internal belief that you need to be on the current version.
In my experience, the biggest part of any upgrade is that analysis process to decide what stays what goes and what changes. The next biggest part is the conversion of data. And way down the end comes the bit involving code. The actual code conversion might be 20-25% of the upgrade project, yet still its the bit people concentrate on the most.
I hope people will read this blog and take your advise.