Microsoft’s Plan for Addressing Obsolete Code in Dynamics 365 Business Central
A Message to Dynamics Business Central Developers, Consultants, Partners, and ISVs: It’s Our Responsibility to Understand Microsoft’s Plan for Addressing Obsolete Code
In the legacy Microsoft Dynamics NAV world, there are always changes to the code, many of them big, like dimension changes and product group changes. This is to address issues uncovered during upgrades or new implementations. Additionally, new features are being added constantly.
With Business Central, the code used in NAV and BC version 14 was moved from C/AL to AL. When that initial transition occurred, there was what one of my colleagues refers to as one big, giant hairball extension of all the code moved over into AL. There was no refactoring, no redesign, no enhancement of code. So, in BC 14, C/AL and AL were nearly 100 percent match in terms of the code.
Moving forward, Microsoft’s goal was to clean up that code—some of which was written 30 years ago—removing some code because it’s no longer used or doesn’t make sense, but also enhancing certain areas. This would also be an excellent opportunity to break down that “hairball” Extension into separate, logical extensions. It’s not that this code (or even the “hairball” Extension) doesn’t work; but with technology advancements and the way Extensions work, there are now modern ways to do it that would improve performance and capabilities, increase the scalability of the product, and make it easier to customize and update.
However, Microsoft understands that, because customers are in SaaS, this needs to be handled in a phased manner so that it doesn’t cause problems during an upgrade, especially in SaaS. So, they came up with a plan that gives us a minimum of one year before code is changed—including warnings that are displayed if a developer is coding in an area that will be changed or removed in the future.
For example – Microsoft replaced a feature called Temp blob management, which is a coding feature around how we shift blobs from different places and then importing/exporting them into the database. That was the first breaking change Microsoft actually replaced in the product. As promised, Microsoft warned us about it beginning with Version 15 and then implemented the change in Version 17.
The Impact of Ignoring Warnings is Serious
Unfortunately, some developers and consultants have ignored these warnings when coding for initial implementations, which will make it more challenging for the customer to upgrade. That code will need to be rewritten before the upgrade because that code will not exist anymore. This can be especially problematic for SaaS customers since they don’t have as much control over when updates or upgrades occur. Another area where these warnings might be ignored is with ISV-developed add-ons. If the customer is using an add-on that has not yet updated their code to comply with Microsoft’s changes, the timeline for implementing or upgrading the system will be impacted.
The impact on SaaS customers is this can create a breaking change. Microsoft begins notifying admins of these breaking changes 60-90 days prior to the new version being rolled out—and with typically 10 to 12 new features in every major release that can result in five to seven breaking changes, the problems can add up quickly, causing interruptions to operations and more.
If warnings from Microsoft about breaking changes that will happen with an upcoming release are ignored, Microsoft will only attempt to push out an upgrade for 90 days before they are forced to remove the extension with the offending code so that they can complete the upgrade because the solution is multi-tenant, and everyone must be on the same version.
Why the entire extension? Because it is not possible to dig into the source code causing the problem. They can’t get inside every source code and identify which code is causing problem. This same rule applies to ISV add-ons. If an add-on is not compatible, the same thing will occur.
A Warning to Developers, Consultants, Partners, and ISVs: Do the Right Thing Now
This serves as a warning to developers, consultants, partners, ISVs, and anyone else who is responsible for Business Central and associated add-on coding and upgrading/updating: Do not ignore these notifications from Microsoft. Make sure you are coding responsibly by having a plan for ensuring your extensions or customized code are property rewritten so that they will not cause breaking changes.
Learn More About Obsolete Code in Microsoft Dynamics Business Central
To learn more, view Microsoft’s documentation on deprecated features Business Central.
To learn how to rewrite code for code that is becoming obsolete, visit ALAppExtensions/BREAKINGCHANGES.md at master · Microsoft/ALAppExtensions · GitHub.