Moving from Dynamics NAV to Dynamics 365 Business Central – Part 3: Code (Extensions, Integrations and ISVs)
You’ve decided on the type of project to employ to move to Dynamics 365 Business Central (Upgrade vs. Reimplement), and you have started to consider your custom data. Concurrent with that latter exercise, you will also reevaluate your customizations - which to leave behind and how to reintroduce those that survive into the BC extension model. Likewise, this is the appropriate time to consider which integrations are needed and which ISVs to add to your installation. In other words, we are no longer focused on what we are taking with us, but how our new house will look and operate.
These decisions will typically represent around half of the overall project budget.
Extensions
First, we will consider how remodeling has changed since we updated the master bathroom in our current home.
Paradigm Shift
Extensions are the new customizations. These include fields added to tables and pages, new tables and lookups, posting changes, (some) new reports and report changes, (some) workflow changes, and (some) integrations to external systems. In Business Central, all coded changes needed to the application are created as extensions. These live outside the base application and are layered on top as you open a page, run a report, or execute a process.
This distinction is important because it means the move to Business Central will be the last traditional upgrade or reimplementation project you should expect. Like the past jump to (or through) NAV2009, the jump to BC is a paradigm shift for the product and many customizations will need to be reimagined.
The BC shift is most clearly understood when we discuss and think about extensions. While we will need to rearchitect many existing customizations, those changes also force us to decouple that custom code from the base application. We cannot just build a new shower into the bathroom like we did before. Our new shower will now come with us the next time we move, so we must approach the new installation differently. This is the paradigm shift – all remodeling stays with us in our next move, or we can optionally leave it behind.
The decoupling of customizations from the base application is a very big win. This allows future upgrades of the product to happen cleanly at the “base” layer, with the extensions dropped back into the resulting database after the base layer is migrated. While occasional adjustments to the extensions might still be needed from time-to-time as new releases of BC add, deprecate or “appify” some functionality, new product versions and periodic build changes are normally non-events. After our move to BC, subsequent moves will allow us to just “snap in” all our previous remodeling.
Carry-Foward Decisions
As part of the effort to get your company to Business Central, you will need to decide which of your past customizations in Dynamics NAV need to be rebuilt as extensions for BC. Because most customizations to NAV do not port directly to BC extensions, some degree of work is needed to get these changes rewritten. Remember, we’re not in BC yet, so the bathroom remodel job we did before needs to be done again – even if we can generally use the same blueprint.
This is where it is helpful to reassess the current workflows utilized in NAV and determine which of those could be handled with “out-of-the-box” features in BC or through integrated applications such as PowerBI, PowerApps, and Dynamics CE. Often these new features and tools can replace an old customization. Maybe your old custom walk-in shower is no better than the one already in your new home.
For those areas where a unique field or behavior is still needed in BC, the old customization is evaluated and ultimately rewritten as an extension in BC. New changes may also be introduced as extensions in order to improve workflow efficiency where the old process wasn’t optimal, and the new process in BC is not an exact fit for your business. Maybe the new shower is great, but you still want to add a different showerhead.
As a rule of thumb, a typical move to BC with a joint review of existing processes should target a 33% customization survival rate. This means two-thirds of the customizations that have been introduced over the years in the NAV application should be left behind. As a related rule of thumb, an initial target of 33% will often end up being 50% when the project is complete. This is because users will often push back on initial management decisions and a balance will need to be struck.
As surviving customizations are gathered, this list is then compared against the custom data points “keep” list from the decision exercise described in Part 2 of this series.
Integrations and Third-Party Applications (ISV’s)
Integrations are the utilities of your home. Your electricity, gas and water feed into your home and waste goes out. Similarly, you may have payroll, expense, and exchange rate services feeding BC, while BC passes back out reporting data or other data and metrics to a reporting tool.
To the extent that the data needs to be kept in sync, and is not handled through a purchased third-party integrated solution, these “hooks” require some development and management.
A third-party solution may alternatively be employed to supplement processing within BC or to integrate BC to another system. These are more like services that keep your home functioning and take some burden off the homeowner. Examples include lawn services or grocery delivery, and for BC include shipping tools and credit card management.
Summary of Moving from Dynamics NAV to D365 Business Central: Part 3 - Code
Decisions related to customizations represent the biggest factor in project scope. Getting your “stock” data to BC in an upgrade, or reintroducing a subset of your stock data in a reimplementation, is mostly a known quantity and repeatable across projects. Likewise, the stages of the project are repeatable. The volume and nature of remodeling to carry forward, utilities to hook up and services to engage, together represent the biggest cost variable.
In Part 4 of the series, we will walk through the remaining project variables including workflow (re)engineering, security decisions, and project teams.
More in the moving from Dynamics NAV to D365 Business Central series:
- Moving NAV to BC Part 1: Overview
- Moving NAV to BC Part 2: Data
- Moving NAV to BC Part 4: Additional Project Variables
- Moving NAV to BC Part 5: Budget and Timeline
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.