We decided to change our product lifecycle policy concerning our add-ins for Dynamics NAV and concerning our extensions for Dynamics 365 Business Central. We (finally) align our release policy with Microsoft's release policy.
Thus, we no longer guarantee the backward compatibility of every new feature we build. We also (eventually) stop supporting NAV (and Business Central) versions that Microsoft doesn't support anymore. However, we offer extended support for business-critical uses of our products. Overall, the streamlined lifecycle helps us gain flexibility, agility, and additional development power. This will further improve our product delivery and the value for our customers.
This blog not only outlines the changes we made. It also reflects the reasons why we are doing so.
We started our business with visual scheduling add-ins and extensions for Microsoft Dynamics in 2013. Since then, we have been treating backward compatibility almost like a holy grail. That means, when we launched a new VPS .NET version for Dynamics NAV (with C/AL integration), we shipped new functionality for all NAV versions from 2009 R2 to 2018. Or, when we launched a new version of the VJS extension for Dynamics 365 Business Central, we shipped new functionality for all BC versions from v.14 to whatever was the current one.
Our customers and partners appreciated this approach. However, for us as developers and vendors of visual scheduling add-ins and extensions, this approach increasingly became problematic for three reasons.
We maintain both add-ins for Dynamics NAV and extensions for Business Central that are made for versions, which are no longer supported by Microsoft. Of course, customers can still use those NAV and BC versions. However, Microsoft will not fix any bugs in these versions.
The older these versions get, the more risky this approach is. This is true both for us (see below) and for our customers. Microsoft explicitly says that they do not guarantee that these versions will work after a platform update (e.g. from Windows 10 to Windows 11).
Fictional example: A customer that runs e.g. on Dynamics NAV 2013 and updates to Windows 11 may experience issues with NAV after that update. If this is the case, Microsoft will not fix this as Dynamics NAV 2013 is out of support since January 2018.
Now comes the hard case for us. If something breaks in a no longer supported Dynamics NAV or Business Central version that impacts our add-ins/extensions, users get an error and come to us. Microsoft will not fix the underlying issue. Hence, we will not be able to fix “our” issue as well.
Thus, there is an inherent risk, that this can happen with the update from Windows 10 to Windows 11. Ultimately, we currently offer a service called “product maintenance” although there might be situations in which we are just unable to deliver that service.
That is something that we decided to fix.
Last, but not least, we face another issue when it comes to Dynamics 365 Business Central. We all have been observing the clockwork-wise execution of Microsoft's product team. As a consequence, Business Central is getting better and better with every semi-annual release.
If we would follow the approach of being backward compatible, we would always have to build on Business Central 14. That way, we could not properly leverage the best-of-breed product and services that Microsoft releases every half year. Instead, we would have to swallow technological (and functional) disadvantages - just for the sake of being backward compatible.
That is something we decided to stop.
For Microsoft Dynamics 365 Business Central, Microsoft applies what they call the modern lifecycle.
It says that
That means if they build a new feature now (with Business Central version 19 being the current version), it will be available for BC 20, but no longer for any previous version.
We decided to fully follow Microsoft’s modern lifecycle. Starting now.
The table below shows the result of this definition and the resulting end dates for our product development, the sales period, and the support. To learn more about these product lifecycle milestones, please visit our lifecycle policy page.
The Business Central-related decision was the easy part. It was easy because Microsoft's modern lifecycle is clear, and there is a consensus in the market about the value of always being on the current version.
However, the world is different among the users of Microsoft Dynamics NAV. Here is what we decided to implement - with immediate effect.
The tables below show the result of this definition and the resulting end dates for our product development, the sales period, and the support. To learn more about these product lifecycle milestones, please visit our lifecycle policy page.