Microsoft Dynamics NAV: Upgrade or re-implementation

There are more than 100.000 companies worldwide using Microsoft Dynamics NAV. Based on our experience over 90% of these businesses are still running older versions of Microsoft Dynamics NAV. This is despite the fact that some older versions are not supported by Microsoft, and that newer versions work much faster, have richer functionality and a more user-friendly interface enabling end users become more productive and effective in doing their job.

The reason for the slow adoption of new releases is usually due to the long and complex process of upgrading. When Partners are asked to upgrade a customer, they often face challenges such as capacity (lack of dedicated resources), efficiency (no available upgrade tools or methodologies to speed up upgrades), and upgrade justification (difficulties in justifying the value of an upgrade).

Re-implementation may appear to be a simpler and less time-consuming approach. However, upgrading can also be simple and fast, especially when performed by specialists with the needed upgrade experience.

In this blog, I want to start the discussion about upgrades versus re-implementations. I have been challenging myself with these questions:

• If NAV upgrades were easy, would I ever consider a re-implementation?
• Will a partner with an upgrade center always suggest an upgrade project?
• Can an end user upgrade without partner assistance. Can the end user re-implement?
• Is it partners or end users that are pushing for one or the other approach – what are the arguments for selecting one model over the other?

Let us start by looking at the differences between an upgrade and a re-implementation.

After an upgrade, a customer will have all historical data in the new version together with any already developed customizations. On the other hand, after re-implementation, the new version contains only master data. In order to carry over required customizations from the older version, they need to be developed from scratch. Of course, customizations from the older version are not always needed, since standard functionalities in the latest version might meet a customer’s needs. In general, a comparison of an upgrade vs. re-implementation reveals that:

• An upgrade is usually faster and less expensive than re-implementation, unless the current solution carries heavy customizations that are outdated, poorly designed or replaced by standard functionality in the newer version.
• Re-implementation requires more customer engagement, but the solution is more flexible, and it is an opportunity to implement a new business vision.

A third option can be to combine an upgrade with a re-implementation.

When choosing the upgrade and re-implementation combination, all data and data models are upgraded to the new version, and then standard functionality is used or customizations are redesigned and developed if needed.

A deep analysis of each specific case should be performed to determine which option is best. Choosing the most cost and time effective option will usually depend on what data and customizations the customer has in the older NAV version, and what needs to be transferred to the newer version. Before making any decisions, the customer should take into consideration a variety of factors, such as:

• System Upgrade path
• Database size & quality
• Customizations & new functionality
• ISV solutions
• Integrations with third party applications
• Budget
• Timeline & downtime limitation for a cutover
• Resources

Based on the factors above, the questions you should ask yourself before making the decision could be:

• What is the version of the source system and is there a clear upgrade path?
• How big is the database, and how good is its quality? Is there a need to purge or archive historical data?
• Are there many customizations, and do we need them?
• Would you like to benefit from new standard functionality instead of upgrading old customizations?
• Are there any ISV solutions or integrations with third party applications, and do they support the target version?

The answers to these questions can enable you to make an informed decision on whether to upgrade or re-implement.

UPGRADE

During an upgrade project, it is very important to understand each party’s role. You can start with a verification workshop to analyze the solution and define the project’s scope and plan. When the upgrade starts, typically a partner does the code and data upgrade. The code upgrade includes various tasks such as merging, fixing compilation errors, re-implementing functionality, upgrading forms’ user interface, and transforming old reports.

The scope of the code upgrade depends on what is decided in the verification workshop. Data upgrade includes performing a test upgrade using a standard Microsoft data upgrade framework and extending the framework by writing various scripts for custom data upgrade. After the code and data upgrade is complete, the upgrade partner does simple testing, including compilation testing, data upgrade testing, and basic functional testing. However, most of the functional testing is usually performed by the end user, but if test scripts are provided, it may be included in the external project’s scope.

RE-IMPLEMENTATION

Re-implementation projects are in reality very similar to upgrades. The diagram above shows an example of how a re-implementation could be organized. Please note that there are many different way to meet an implementation target, so I have included the illustrations just to compare and identify typical differences.

Once requirements are collected and fit-gap analysis is performed, the end users will be busy with the verification workshop where they define the scope and plan the project, split tasks, and define responsibilities.

The partner’s major involvement is in redesigning and developing customizations, as well as data migration and data migration testing unless you have an internal team that does this. The development team, followed by user acceptance testing, does functional tests. Once everything is tested, the test go-live procedure starts. I recommend performing at least two test runs before going live. The partner or your internal business application team completes user documentation and end user training.

SUMMARY

A decision to upgrade or re-implement is always a challenge. There’s a list of critical issues to address, and there is not a single or simple answer to the question of whether to upgrade or re-implement. The decision depends on various criteria; not only those mentioned in this document but also based on a customer’s or partner’s resources, time, and budget available for the project. It is not an easy decision, and the project must be carefully conceived and skilfully executed. That is why it is important to have experienced specialists on your side. You benefit from an experienced upgrade team including consultations, tools to speed up the project, a fixed price to make sure you stay on budget, and the peace of mind knowing that your project is in good hands.