Read Part 1 here: What if I Do Nothing?
There are various factors to consider when performing an upgrade from Microsoft Dynamics NAV to the most current version of the software, Microsoft Dynamics 365 Business Central, or D365 BC for short. Should I reimplement (meaning implement the software with a blank database) or perform a technical upgrade (bring forward all the historical data transactions, customizations, and have everything we had from our original system in the latest version)? There are also other possibilities that lie in-between, such as: can we bring forward just some, but not all of the data or can we pick and choose which customizations to bring forward and which to leave behind?
Upgrade or Reimplementation Scenarios
In a pure upgrade scenario, you’re typically going to bring forward all of your historical transactions, all of your master records, generally referring but not limited to Customers, Items, Vendors, Chart of Accounts, plus all of your customizations. In the new version that data is migrated, fit into terms of D365 BC, all the customizations are brought forward and refactored into the new code base if it does not simply compile with existing tools. By contrast, in a reimplementation scenario, you’re essentially starting a new implementation from scratch, where we will migrate master records, set beginning GL balances, Open A/R, and Open A/P, but no historical data or customizations will be brought forward.
The other large factor to consider in either an Upgrade or Reimplementation scenario are ISV (Independent Software Vendor) add-ons. Did the ISV release a new “extension” version available in Microsoft AppSource (similar to Google Play Store or Apple App Store for your smartphone), is there still a need for that functionality, does D365 BC now have that functionality out of the box, or is there something better? In the past, many upgrades were held up because a particular publisher or ISV did not have a business-critical add-on ready for the new version of NAV or BC. Additionally, Microsoft now has a rigorous certification process in place for an ISV to qualify to list their app or extension in Microsoft AppSource which lowers your risk in adding it to your system.
Customizations can be a challenging part of Dynamics NAV software upgrades, the reason being, when you modified base NAV objects (Tables, Forms, Reports, etc.), they were tantamount to one-off “version 1” software development that had to be maintained and either had to be compiled or refactored to work with conflicting code published in the new version of the software. Because of the new paradigm where Microsoft allows no direct modifications of base BC code, where all customization is accomplished via published events and extensions, you will never be caught in this scenario again. In addition to risk, mods form a large part of the cost for an upgrade.
Reasons to Reimplement
You may think that starting from scratch in a reimplementation would typically cost a lot more to perform, however, that may not always be the case and there may be many good reasons to reimplement such as:
- The business today is no longer the same business as it was yesterday when we initially implemented our ERP software. Business requirements or goals, structure, processes, or workflows may have changed or are different today than they were when initially implemented.
- People may have changed. It was highly customized and those that understood and needed the customizations are no longer around or in the business today and those customizations are either no longer required or the software now in the current version can perform those customizations out of the box. Also, business process, services, or products may have changed thus obviating the reason a mod or customization was performed.
- There may be issues with the historical data that you do not want to bring forward into the new system. Those issues may be preventing accurate reporting. Additionally, if you eliminate modified Tables where a Field has been added or an entirely new custom Table and you try to migrate the data forward into the new version, it will have nowhere to map to. Performing data cleanup can be costly and time consuming. Reimplementing provides you with the opportunity to start over and eliminate any issues with past data or customizations.
- Past volume of data and customizations can result in system performance issues, such as slows, locking, or other inefficiencies. You can always keep a copy of the old system for reference or audits until no longer needed.
- You may be several versions behind and data must be jumped through certain key versions in the migration process, adding cost to an upgrade.
Reasons to Upgrade
There may be a lot of good reasons to perform an upgrade:
- Business needs or requirements that the older software met have not changed all that much, and you just need a newer version to work better with current technology.
- You still really need your historical transactional data.
- Past customizations are still relevant. While Dynamics NAV and D365 BC are general purpose ERP system, i.e., they do 80% of what any business needs, such as GL, AP, AR, Cash Management, Inventory, Procurement, Warehouse, etc., and the 20% is filled with ISV add-ons, customizations, etc.; the new version of the software never really filled those gaps specific to your business, business processes or reasons why you had the customizations performed in the first place and you can simply refactor or even completely rewrite those customizations if they won’t simply compile over with existing tools.
- You do not need to worry about losing data or customizations or other work that still adds business value today.
- You can usually find new versions of past ISV add-ons rewritten as extensions in MS AppSource. If not, there are usually similar competing products that perform the same functionality but are now compatible with D365 BC.
The issue with a “hybrid” approach is that picking and choosing which customizations or data to include in either an upgrade or reimplementation can require a ton of analysis time and cost which might be better spent going with one extreme, bring it all forward, or the other, start fresh. There is usually no way a Microsoft Partner, even if they implemented and supported your Dynamics NAV solution for years, will know or understand how each piece of customized code was supposed to work without detailed review of the code and how the users utilize it. Multiple resources may have worked on different pieces in the past, documentation may be lacking or nonexistent, or this may not be the same Partner that initially implemented your system. Additionally, the users may not know the difference between base NAV and code that has been customized and you can get into a blind-leading-the-blind situation. It takes a very manual process of end-users, Partner Consultants, and Devs to analyze existing customizations and how they’re supposed to function, who uses them, whether or not they’re still needed or used, if D365 BC now performs that functionality, is there a better way or solution, etc.
Whether upgrading or reimplementing, the primary reason to stick with Microsoft Dynamics software is that you still have a high degree of familiarity that will shorten the learning curve for your team. Even though the UI (User Interface) and UX (User Experience) will be a bit different and much improved, under the hood the basic functionality and inner-workings that you’ve come to know and love will still be the same or at least mostly recognizable. The important criteria to consider includes business goals and initiatives, functionality, processes, data, reporting, siloed information, customizations, ISV add-ons, time, costs, and associated risk. One should also consider the cost and risk associated with not upgrading or getting to the latest version asap. All this should be measured with an eye to risk versus rewards and benefit. See Part 1 of this blog for more information.
Amongst the many benefits, along with the goal of reducing customizations and upgrade costs, in Microsoft D365 BC SaaS (Cloud) product, Microsoft provides the infrastructure in the background and the software will always remain optimized with up-to-date monthly Cumulative Updates (“CU’s”) containing hotfixes, patches, and enhancements to the platform and application with major releases every 6 months in April and October. What this means is that you will never have to purchase or maintain another server and you will never have to perform a major ERP software upgrade again. If you have multiple D365 BC databases distributed amongst different countries, they will always remain in sync on the most current version of the software no matter when they are deployed with high availability and disaster recovery in place (HA/DR) plus heightened up-to-date security thus reducing the various risks along those lines while maximizing uptime. Because of the new technology paradigm where Microsoft does not allow base code to be modified and customizations and add-on products are achieved through published events and extensions, you will not be hindered from being on the most current version of the software due to an ISV not having their solution ready or some custom code that needs to be refactored to work.
The flexible named user model also means that you can easily add or remove users to properly fit the size of your organization and not overpay for unused seats. Gone are the annual software maintenance fees in the new D365 BC SaaS model. Subject to licensing, you will be able to leverage multiple Microsoft products and integrations that work “better together” including Office 365, Power Platform (Power BI, Power Automate, Power Apps, Power Virtual Agents) low code/no code, and the MS App Store loaded with ready-to-go D365 BC solutions to fit a wide range of business needs.
If you have any questions about reimplementation or upgrades, please connect with us.
Are You Receiving Our Newsletters?
Subscribe to receive our monthly newsletters with the latest updates all in one place! Get important product information, event recaps, blog articles, and more.Subscribe