Companies planning to migrate from Dynamics AX 2012 to Dynamics 365 need to carefully evaluate their customized features, because recent technical mandates by Microsoft have fundamentally changed how those customizations are developed.
Overlays, the now-outdated way to implement customer-specific functionality under Dynamics AX, involved adding customized programming within Microsoft's code. Using overlays is no longer possible because Microsoft has sealed its code base, beginning with the 8.0 release. So customized features must now be developed as extensions—code that is compiled into a separate file that runs alongside Dynamics 365's core functionality.
This change means that as you upgrade to D365, it may no longer be possible to add some features that were implemented through overlaid code, or it may require more work than the customized functionality justifies. As a result, you need to consider your existing customizations very carefully.
For example, if your business processes change, a custom feature that made sense a couple of years ago may no longer be applicable to your daily operations, or may be used infrequently. In these cases, the work needed to re-implement the feature as a D365 extension may not be worthwhile.
Microsoft's shift from overlays to extensions offers more flexibility for most customizations, but the potential complexity of evaluating past customizations that used overlays—and understanding if that code can be re-implemented as extensions—means you have to consider how easily customized features can be redeveloped, or whether you really need them.
The amount and complexity of the code supporting a custom feature increases the overall difficulty of an upgrade, because all of that customized code has to be reviewed. The feature then has to be validated as is, re-engineered as an extension if possible—or eliminated.
Some companies may find that their customizations transfer over relatively painlessly. For others, the challenge of moving to extensions can mean that revamping a business process to align more closely with common industry practices is a better option. While this may seem like a setback if you're used to customizing your implementation, reducing customization can lead to streamlined business processes that are more efficient and pave the way for smoother upgrades later on.
As an alternative to abandoning features that rely on code that formerly could be overlaid, you can ask Microsoft to make certain features of Dynamics 365 F&O compatible with extensions. But because it takes time for Microsoft to review a request (and there is no guarantee that they will approve or institute it), finding ways to redesign or potentially eliminate the customization is usually a faster and more effective approach.
An effective migration from AX to Dynamics 365 should start with asking whether existing customizations are still needed and whether business processes can be streamlined. Talk with your business users and your Dynamics software partner to understand the true value of each customized feature. It's critical to collaborate to decide whether it's worthwhile to spend money on an aspect of the system that may not be needed for your core business processes.
Understanding what's important is a key step in evaluating which features need to be retained or redesigned, and which customizations can be removed to save time during the upgrade process.
Keep in mind that evaluating past customizations can be a manual, time-consuming process. The more customized code you have, and the more complex that code is, the harder you will have to work to understand which features really are important.
Microsoft offers a code upgrade wizard that converts your AX 2012 code (via model store) to the D365 metadata format, but that conversion is a preliminary step that basically gets you to the starting line of reviewing the code's functionality. Because the wizard doesn't automate the code analysis, the code needs to be reviewed manually to understand its original goal, how well it was performing, and whether its features can be replicated as a Dynamics 365 extension. It also frequently requires effort just to get the new D365 code to compile.
As an additional benefit, reducing the amount of customization in your Dynamics 365 implementation will make future upgrades easier and faster to deploy. You won't have to re-examine your customized code and test it for potential conflicts with Microsoft's latest updates.
Similarly, reducing customized features and running a D365 implementation that is closer to the default product makes support issues simpler to resolve, because you don't need to evaluate how the customized code interacts with the base programming.
The bottom line? In many instances, customized features in Dynamics 365 can add efficiency to your work flow, but it's important to evaluate how those features fit within the broader D365 application. And as you consider upgrading to Dynamics 365, it's also important to collaborate with your implementation partner to understand whether you need to change or eliminate your customizations or processes to align with Dynamics 365 functionality.
