C/AL to Extension transition alternatives: how to choose wisely?

Tuesday, May 5, 2020

When transitioning from C/AL to Dynamics 365 Business Central Extension, you will encounter several transition alternatives, and it might be tricky to make the right choice. If you choose one alternative over another, you can get a significant increase or decrease in the number of hours that are required to move the solution from C/AL to AL. For example, the average number of modifications that an add-on solution in C/AL has is 43,656, and the average number of hours required to move the solution from C/AL to AL would be 2,439. But, on a different scope, this could decrease to 2,237 hours. Therefore, it is wise to investigate the transition alternatives that we have when moving from C/AL to Extension, and to know how to differentiate between them to be able to make a smarter choice.

What options do you have when moving from C/AL to AL?

There are 3 options when moving from C/AL to AL: Modified Base App, Hybrid, and Extension. The least recommended option is Modified Base App. Let’s look in more detail why we do not recommend it.

Modified Base App

Modifying the Base Application of Business Central means that the additional changes are added directly to the standard objects in the Base Application on C/AL or AL. A classic example would be opening the items table and adding additional fields, modifying the fields, or even deleting some of the fields that you may not need.

The graphic example below details the current situation of a modified Base App solution and how a solution can be customized. Since we’re going to use this graphic several times in this article, let’s take a closer look at the abbreviations:

• Customizations are added directly on the standard objects (Cust1, Cust2, Cust3).
• Customizations can be done by adding custom objects directly on the Base Application of Business Central (Cust4, Cust5).
• Customizations can subscribe (“S”) to standard Business Central Publishers (“P”).

The modified Base Application has the following issues:

1. Difficult to maintain. When all modifications are being done on the Base Application, a separate version control process may be needed to maintain the custom functionality added to Business Central.
2. Difficult to install. To install a modified Base Application, the standard Business Central Application will need to be uninstalled before installing the full modified Base Application.
3. Not eligible for AppSource. If any modifications are done directly on the Base Application, the solution is not eligible for AppSource.
4. The upgrade process is difficult. Every time an update on Business Central is needed (CU Update, Major Update), a full Upgrade process will need to be gone through.

When upgrading the Modified Base App solution from an older Business Central version to a newer one, you need to go through the following steps:

The first step is to take the full solution with the standard and custom objects and find out what differences were added to this solution. To find out, you need to compare it with the standard objects and get the deltas between these two solutions. Once you have the differences that are your specific code changes, the second step is to merge them with the new version of Business Central’s standard objects to get the upgraded solution with modifications.

However, this process is not as easy as it may seem, because you would have to move the code line by line, and when doing that, several conflicts may occur, such as the need for function reimplementation or any other conflicts. That means that upgrading the solution may need more effort and attention. And the biggest concern when upgrading a Modified Base App to a newer version of Business Central is that each time, you need to go through the same long and tedious process repeatedly. That’s why we do not recommend modifying the Base App, so let’s look into other alternatives to move from C/AL to Extension.

Extension

The other alternative is to transition to a full Business Central Extension. In such a case, the customizations are completely separated from the Base Application of Business Central, and the Base App is left fully intact.

The pros of having an Extension would be as follows:

• Easier to maintain. There won’t be a need to find specific code changes anymore, as you’d have to do in order to upgrade the Modified Base App. All customizations will be in one place and you would be able to use Extension in any way you like; even the upgrade process is going to be a lot easier.
• Easier to install. To install an Extension in an on-premises version of Business Central, you have to simply publish and install the Extension and you’ll be able to use the application straight away. It is also easy to uninstall an Extension. You can do it directly from the Extension management page on Business Central.
• Possible to publish on AppSource. If you have a full based Extension that fits all AppSource requirements, you can publish it on AppSource.

There are a lot of pros of having an Extension, but you should keep in mind that for a moderately sized solution it won’t be simple to move from a C/AL-based solution to an Extension. Next to that, it might not always be fully possible to move to an Extension without much reimplementation effort. For example, let’s look at the old and reliable RTC Client of Business Central/NAV below, where we have the Job Journal page opened. Let’s say that our customer needs to have an additional Type called “Bicycle Service”.

The “OptionString” change was added directly on the Job Journal Line table. When moving to the newer version (e.g. 150 of Business Central), you will find out that the option fields are not extendable there, and you will have to think about how you might reimplement this functionality. There might be many more conflicts that could be difficult to resolve when moving from C/AL to AL. Therefore, let’s investigate the other options that we have when moving from C/AL to AL.

Hybrid model

The Hybrid option is having the best of both previously mentioned options in one. In a Hybrid solution, you would have an Extension in which most of the code is run, and where it is not possible to move from C/AL to AL you would leave some modifications in the Base Application.

How does a Hybrid solution differ from the other transition alternatives?

• Easier to maintain. With most of the modifications already moved to separate Extensions, there are less modifications made directly on the Base Application. If you cannot move some of the modifications to Extensions now because it requires a lot of reimplementation, you can wait and leave them in the Base Application.
• Difficult to install. To install a Hybrid solution, you will have to uninstall the Base Application and install the Modified Base Application on top. After the Base Application is installed, the other Extensions dependent on the application need to be installed.
• Not eligible for AppSource. If any modifications are done directly on the Base Application, the solution is not eligible for Therefore, the Hybrid Extension model is not recommended for ISV providers who want to publish an Extension on AppSource.
• Receive Microsoft’s help. When moving to Extension, you need to move the code to Subscribers, which then needs to connect to Publishers. It can happen that the Publishers in the Standard do not exist. In such a case, you can request Standard Event Publishers on Microsoft’s GitHub page (https://github.com/Microsoft/ALAppExtensions). You can ask for a specific Publisher to be added in the specific place of the code, and in the next Business Central release or the one after that Publisher may come up in the Base Application; therefore, you can easily move the code out.

To sum up, there are 3 transition alternatives when moving from C/AL to AL.

Let’s compare all 3 options to see how they differ:

Which C/AL to AL transition alternatives can be used on the different Business Central target platforms?

As you know, Business Central has two target platforms, On-Premises and SaaS, and these 3 transition alternatives are not available on both platforms.

The On-Premises version of Business Central is on our own machines, on our local servers, on any cloud environments, where (most of the time) we fully control the infrastructure. We can use the SQL Management Studio to access the databases, we can use PowerShell to run specific scripts on the solution, we can publish a separate Base Application, and we have the full control on the platform.

Business Central SaaS (Software as a Service) is different from the On-premises version of Business Central. On Business Central SaaS we cannot control the infrastructure and we use Business Central through a browser or a web app. Business Central SaaS is highly recommended for SMBs as they can use Business Central at a lower cost without the need to worry about infrastructure, security, etc.

On Business Central On-premises, you can use any of the 3 C/AL to Extension transition alternatives: Extension, Hybrid, and Modified Base App. On Business Central SaaS, since you cannot modify the Base Application, the only way to have modifications is by having an additional Extension.

This is important to know if your goal is to transition to Business Central SaaS. To find out more about what transition steps you need to make to move from C/AL to AL and ultimately have a SaaS-ready solution, read our next blog post. You can also watch Mantas Paskevicius’s webinar recording on this topic on YouTube.

Watch the webinar

Read the next blog post