Network of MS Dynamics D365, AX, NAV, GP, SL, CRM, RMS, POS professionals › Forums › Microsoft Dynamics NAV / Navision › NAV Installation & Administration › How we can upgrade the Dynamics NAV 2016?
Tagged: Dynamics NAV
July 11, 2019 at 6:04 pm #20781
How we can upgrade the Dynamics NAV 2016?July 11, 2019 at 11:34 pm #20895
When you think about upgrading to Microsoft Dynamics NAV 2016 does your blood pressure go up? Do you fear disruption of operations, customization needs, integration migrations, and—here’s probably the scariest—a substantial price tag? You’re not alone. It is the experience of most of us that, with upgrading sophisticated and customizable software, such as Dynamics NAV, comes risk and cost. But upgrades don’t have to be a cost sinkhole. After years of executing 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 impact the cost of an upgrade, but there are things you can do to lessen the blow considerably:
1. Custom Modifications
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, the 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. Locus IT has consultants who know NAV very well and can help in making decisions regarding whether to bring 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. 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 Microsoft Dynamics NAV 2016 we also have a new development feature called events and subscriptions. An event is a specific point in the 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 code units that are outside the standard object range, and set subscriptions within the standard objects. Though this does result in more work in upgrading to Microsoft Dynamics NAV 2016, this is a one-time effort. And, future upgrades are less costly because of this new feature.
2. 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 significant impact 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 Locus IT 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, 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 Locus IT 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 Dynamics 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 a 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 Microsoft Dynamics 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.
4. Version Jumps
As you may expect, the age of your database has a significant impact 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:
5. Versions lower than 2.6
Version 2.6 through Version 3.0
Version 3.7 through Version 4.3
Version5.0 through Version 2009 R2
Let’s say your current database is version 5.0., in order to upgrade your database to Dynamics NAV 2016, we would first upgrade it to NAV 2009 R2, then to NAV 2015, then to NAV 2016. That’s three versions “jumps.” Each one is different in complexity to the others. These jumps are where we primarily handle data structure differences, such as the removal of deprecated fields, the addition of new fields, and so forth.
Some of you that have worked with NAV for decades, will remember when the BLOCKED fields on the customer and vendor cards used to be just a Boolean checkbox. But along the way, it was decided that these fields should be optional 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. 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.
6. Database Size
There’s a huge difference in the time it takes to upgrade a 20GB database and a 400GB database. Time is a big factor 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 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. Locus IT can work with you to find the best method to resolve the database size issue for you. We can do data compression or data filtering to reduce the database size.
Your business might be one of those that just need 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.July 12, 2019 at 11:32 am #20787
If you are upgrading a solution that depends on functionality that is deprecated or changed in the default version of Microsoft Dynamics NAV 2016, you must verify that the upgrade codeunits migrate data correctly.
You must be logged in to reply to this topic.