The post Dynamics NAV Upgrade Process appeared first on Dynamics 101.
Every product is subject to the release of a newer version, offering enhancements and new features. The new release of Microsoft Dynamics NAV 2013 is no exception. The product attracts customers because it is typically a good fit for most industry needs right out-of-the-box, as well as offers easy options for improved configuration and customization. However, many core changes in the application require a more complex approach to the upgrade of the product. In this article, we are going to look at the process of moving to the latest version of Dynamics NAV and the steps it involves, both from the partner and end user side.
The following illustration depicts the basic steps of the upgrade process:
Let’s take a closer look at each of these steps.
Requirements
At this stage, the partner investigates what needs to be done to upgrade the Dynamics NAV system. This process typically includes sending a questionnaire to the client, where the following is clarified:
- Source and target versions of Dynamics NAV
- Integrations/add-ons detected in the database
- Upgrade options to include (data upgrade, SQL optimization, etc.)
- Testing strategies and responsibilities
Alternatively, these points can be discussed with the client onsite. This is a very important step of the process, as the quality of the upgrade directly relates to setting up clear expectations from both the client’s and the partner’s perspective.
Discovery Analysis
This is an optional step of creating a special document with findings and recommendations as to the project scope. A detailed analysis is carried out on the source database, identifying the customizations and grouping them by functional area. Later on, these customizations are discussed with the client and considered for appropriate handling: removal, upgrade, changing. This step is highly advisable for heavily customized databases in order to help with code cleansing.
Code Upgrade
This is the core process of upgrading from the old Dynamics NAV version. Every object in the source database is compared to its “clean” version of the source database and also compared to the “new” target version of the database. Any asymmetry in code between these three sources should be analyzed and considered as custom code. This custom code would need to be merged into the target database.
It is usually helpful if the customizations are clearly marked in the Version List of the object, as well as in the in-line code comments. However, often this is not the case, which makes comparison more complex.
Once the customized objects are identified, they are considered for code merge. During this stage, the custom code is merged into the clean target object and tested for Import and Compilation in the new version of the database. Any errors that evolve during this process should then be fixed.
RTC Upgrade
This option occurs in the following cases:
- For upgrades starting from Dynamics NAV 2009 version or later.
- If the client is going to use the new Role-Tailored Client.
At this stage, a list of objects is defined that need to be transformed. This is often discussed with the client in order to reduce the project estimates, as this stage is quite time-consuming. Among the objects which require transformation are:
- Forms which would need to be transformed into Pages.
- Reports which would need to be upgraded to the RDLC layout.
- Dataports which would need to be transformed to XMLPorts.
- MenuSuite Objects which would need an update to the new structure.
Additionally, depending on user requirements, this stage would also include the creation of new, or customized existing Role Centers, as well as UX-tailoring.
Data Upgrade
By this stage, all required objects are upgraded to the new target version structure and the data is ready for migration. The first run is trial and is made in the test environment.
This step involves running the Microsoft Upgrade Toolkit on each of the companies in the database. Sometimes, the toolkit will require customization. These modifications are documented and provided to the client in the release notes. The brief data conversion workflow is as follows:
This step requires thorough testing from both the partner’s and client’s side. After the test acceptance, the data is prepared for the upgrade on the Live System. Usually, weekend days are booked for this process so the production database can go offline safely.
Database Tuning
This is an optional step offering a wide range of database optimization services. This is especially useful if the source database is to be upgraded from the Native to SQL option and the Dynamics NAV version is lower than 5.0.
The process includes various options for improving the client-server interaction, including:
- Index optimization
- Re-coding of low-performance objects (e.g. reports which pull ledger data can run for hours if the database is large)
- Updating statistics
- Updating the code with the following new C/AL functions:
FINDFIRST
FINDLAST
FINDSET
ISEMPTY
MODIFYALL
DELETEALL
COUNTAPPROX
User Acceptance Testing (UAT)
The User Acceptance Testing is the final step in the upgrade, as it defines the test results and the quality of the upgrade. Any comments from the testing should be documented (e.g. in the Scope of Testing document).
Looking over the upgrade process of the Dynamics NAV system, it is obvious that this process needs to be carried out by an experienced team who not only will be able to handle any issues related to the upgrade, but also will be capable of advising the client on the best options for handling modification conflicts.
Upgrades are challenging, seemingly risky ventures, which require a solid team and plan in place to ensure success. However, the benefit of upgrading is obvious – keeping pace with new technologies that will surely be beneficial to the organization. Such benefits are many, but are the topic of a separate discussion.
