Upgrading to Microsoft Dynamics NAV 2016: How You Can Reduce the Cost
When you think about the prospect of upgrading any business-critical software, does your blood pressure go up at the thought of disruption of operations, complicated data, customization, integration migrations (and maybe even losing some along the way), and—here’s the worst—cost? You’re not alone. It is the experience of most of us that, with upgrading sophisticated and customizable software, comes risk and cost. So, like many, you either abandon or put off the upgrade, which keeps you from realizing its benefits.
But upgrades don’t have to be a cost sinkhole. After years of managing Microsoft Dynamics NAV upgrades and honing a practice with a dedicated upgrade team, we have learned a great deal and have perfected processes and procedures. The result: Smooth upgrades that don’t break the bank.
There are certain factors that affect the cost of an upgrade. But with each, there are things you can do to lessen the blow considerably:
All businesses have some custom modifications. But when it comes to upgrades, there’s a big difference in having a few modified reports and having a complex business specific integration, such as a reservation system built into the sales application. When there are large customizations to your database, cost is added in that these have to be merged into the new version of NAV code. Often the code will also have to be rewritten, as is the case with dimensions in a pre-NAV 2013 version.
What can you do in these situations? Check to see if the NAV version you are upgrading to has standard features that handle some portion of that modification. ArcherPoint has consultants who know NAV very well and can help in making decisions regarding whether to bring a customization forward or not.
If the customization is not in standard NAV, another option is to see if there is a NAV Add-On that fits your needs. The upgrade Sales team can assist you in finding a software solution that is specifically for NAV to fit your needs. Yes, this software will have to be merged into your new NAV code as well, but ISV software typically has a smaller footprint in the standard NAV code compared to custom written code. A good NAV Add-On will have most of their objects outside the standard NAV object range and in a separate object ID range. Those ISV objects that are not standard NAV objects can simply be imported to your database. The few objects that integrate the software product with NAV can be merged, and usually fit like puzzle pieces since they will come from the same version.
With NAV2016 we also have a new development feature called events and subscriptions. An event is a specific point in code, and a subscription is a property given to the event to allow custom code to be ‘subscribed’ to that event so it is processed. With this new feature, we can move your custom code into codeunits that are outside the standard object range, and set subscriptions within the standard objects. Though this does result in more work on an upgrade to NAV2016 (on a one-time basis), future upgrades are less costly because of this new feature.
Custom and Customized Reports
‘Custom’ reports are those that have been written specifically for your company. These are usually within the 50,000-59999 range of objects. A ‘customized’ report is one that has been changed from its standard NAV version to fit your company’s needs.
The number of custom reports and customized reports in your database can have a great effect on your upgrade cost. Before the introduction to the RTC client, all reports were written using the old classic client Report Designer. But beginning NAV 2013 that tool is gone, and reports are now written in RDLC code using Visual Studio.
Each report upgraded from a pre-RDLC version must first be transformed to get the report code into the database. Thereafter the layout must be designed in Visual Studio. This process, though tedious and filled with challenges, is something our ArcherPoint developers have mastered. They have transformed and upgraded thousands of reports. In most cases the new reports are of a higher quality than the old ones. As they find issues in reports such as columns that are too narrow, incorrect totaling, poor document spacing and so forth, they resolve the issues.
The way to reduce costs on custom and customized reports is to take a hard look at what your users are really using. Over time, your database users come and go, and with them go some of the reports needed. For example, one accountant may live and die by a specific report, while another accountant will use an account schedule. We have a tool we can deploy in your database that will gather data regarding the reports that are being used. This provides a clear picture of what you need to upgrade. If you’re thinking of upgrading in the next year, we recommend you have ArcherPoint put this in your database as early as possible to gather this data for you.
Dataports were used in versions before NAV 2009 R2 to import or export data. But beginning with NAV 2013, Dataports have been replaced with XMLPorts, a different object type. Dataports no longer exist. Any Dataports that you are using need to be rewritten as XMLPorts.
Because Dataports are often used for temporary measure, like adding data to a new field in a table, or setup of a new application, you most likely do not need all the Dataports you have. Talk to your users and determine which are being used. Then look at the new capabilities of NAV to see if those will replace any of the Dataports being used.
In NAV 2016 you can export a journal to Excel, modify the data, and import it back into the journal. Sometimes this exercise can eliminate the need for a Dataport/XMLPort.
As you may expect, the age of your database has a significant effect on the cost of an upgrade. The older the database, the higher the cost. The reason for this is that it adds steps to the upgrade process. At certain versions, there are “jumps” to get to a new version because it requires a separate migration toolkit. Here are the current “jump” versions:
- Versions lower than 2.6
- Version 2.6 through Version 3.0
- Version 3.6
- Version 3.7 through Version 4.3
- Version5.0 through Version 2009 R2
- Version 2015
- Version 2016
Let’s say your current database is version 5.0. In order to upgrade your database to NAV 2016, we would first upgrade it to NAV 2009 R2, then to NAV 2015, then to NAV 2016. That’s three version “jumps.” Each one is different in complexity to the others. These jumps are where we primarily handle data structure differences, such as removal of deprecated fields, addition of new fields, and so forth.
Some of you that have worked with NAV for decades as I have, will remember when the BLOCKED fields on the customer and vendor cards used to be just a Boolean check box. But along the way, it was decided that these fields should be option fields which further define the blocked status. During the jump the Booleans in a client’s database have to be converted to one of the option fields, typically the “ALL” option.
Also in the older versions we did not have the Detail Customer Ledger Entry and Detail Vendor Ledger Entry records. When clients are upgraded to the current NAV version, the migration toolkit will use the existing data to create these records. This is yet another time consuming activity along the upgrade path.
Sometimes a table is removed from the NAV standard objects, and the data is merged into an existing table. All ISV product tables also have to be merged at each jump level.
This is one of the reasons we encourage our clients to stay current on their upgrade path. One key signal to look for is when Microsoft stops supporting your version. When that happens, by all means, you need to upgrade to keep the costs down.
There’s a huge difference in the time it takes to upgrade a 20GB database and a 400GB database. Time is a big factor for you, the client, since the go-live process must be done between production days with your business use of NAV down. We try to always do this on a weekend, or whenever is most convenient for your business. But sometimes the database is too big to migrate to the new version, going through all the jumps, over a single weekend. When that happens, we do have a couple of things we can try, but it takes testing and time metric tracking to determine what will give us success, and that incurs costs as well.
What can you do to reduce the size of your database? First, talk to our Sales team. If you are dropping a major customization from your database, the data related to that customization will be dropped as well. That goes into consideration. If you are a heavy transaction house, a lot of the old style dimension data will be dropped as you gain the power of the new dimension functionality introduced in NAV 2013. ArcherPoint can work with you to find the best method to resolve the database size issue for you. We can do data compression or date filtering to reduce the database size.
Your business might be one of those that just needs to drop a ton of old, cumbersome data, too! For you we recommend a reimplementation, where we move your business to the new version of the software with the same master tables (customers, items, vendors, etc.) and no transactional data. Your current version can remain as a reference tool, which eventually you will not need.
There are many ways to get you to the most recent version of NAV and make it cost effective. Talk to the ArcherPoint Upgrade Experts today to find out what we can do to help you.