My intentional plan was to share a small blog about the Fall release of Business Central. Well – it turned out I had more to say than I imagined beforehand ;-).

I would like to focus on one point, where I’m not going to make myself really popular, as I notice quite a lot that people kind of disagree with me quite a lot :-). But that’s ok .. I don’t mind different opinions, as long I’m allowed to express mine ;-). Please take everything that follows as my opinion, and my opinion only.

Fall 2019 release

In Fall (probably October), we’ll have yet another major release of our beloved product Business Central. And Microsoft already shared their focus points in this slide:

Two points are totally not a surprise, I guess, as I announced that already:

  • The fall release will not contain C/SIDE or C/AL!
  • The fall release will not contain the Windows Client!

What I would like to do, is actually focus on the last bit. Extensions! There is going to be a strong focus for you to be able to do what you want, completely with Extensions. And even more, that last sentence:

“In the future, on-premises will follow the cloud rules”

What does that mean?

I understand this sentence can be understood in a lot of ways. And I wasn’t at Directions ASIA, so I wasn’t able to get the context of this – so I’m just going to make my own assumptions (disclaimer ;-)).

Just look at this twitter-thread from AJ and this one from Tobias. It kind of expresses some things that I will explain going forward – but at least, might give you an idea on how other people think about it as well.

Basically, I have a few assumptions that I’m going to assume is going to be the right assumptions. Assumptions² if you will .. :

  • Microsoft wants all of us in the cloud (I think that’s an easy one)
  • With Extensions only, not customizations.
  • In order to do that, it needs to bring us as close as possible to be able to be as flexible as possible to do what we do today – with Extensions. I think that’s a very fair focus.
  • Therefor – we should apply the same paradigms onprem, as we would for being “cloud ready”.
  • Customizations are not “cloud ready”. So at some point (not in Fall), customizations are NOT going to be possible anymore – even on premise.

Again, just my assumptions.


We all like customizations, right? Well, to be honest, no. Some say it was the one thing that made NAV what it is today. Others say it implemented simplicity. I say: the simplicity to change the base app has kind of poisoned us. Sure, it’s easy on short term. But why-o-why are so many customers still running on old versions?

In anything I do with C/AL, NAV, … , I have had a strong focus of “upgradability”. Implementing with Hooks. Adopting Events. Adopting Extensions V1 .. all just to be able to upgrade. That’s my history. And a lot of my contributions were focused on that as well. Just take these blogposts into account:

I can tell you one thing: customizations do not facilitate upgrades in any decent way. From the moment you start customizing, you start creating upgrade-challenges. That’s the simple truth. One might not care, but we’re talking “cloud ready” here … and software with upgrade-challenges is all but “cloud ready”.

For a long time, Extensions has been the focus to solve that challenge. The feedback from some in the market though is a bit hesitant:

  • “I can’t do everything with extensions”
  • “I don’t have the events I need”
  • “I can’t add document types”
  • “I can’t …”

And you are all right, most probably. But in many (I won’t say all) occasions, those people make one crucial mistake. You try to do what you have been doing. That’s not how evolution works. With (r)evolution comes change. With change comes adaptability. You need to adapt. You need to change. And in terms of products, software (and yes, also customer customizations), that means: refactoring and reimplementation. Don’t act like the software you wrote 10 years ago, is still valid today. Cars are re-invented ever so long – but software needs to live forever? I don’t think so…

Our focus

The focus in our company has been extensions for a long time. For sure, we are not able to do that for everything – and for sure, we are still doing customizations. More than I want to admit. Simply by the fact: our latest product release is still C/AL today.

But … there is a focus:

  • No hybrid. What is hybrid? Why not? Well, I blogged about that here. So it’s either full C/AL or full AL. When we need to use our product today, it’s full C/AL. If not, it’s full AL. Luckily, we have quite some cases we can go the AL directions ;-).
  • We are rebuilding (from scratch) our product this year. No migration, but a complete rewrite. Because in my opinion, it’s the only thing that really makes sense for us.
  • When it’s AL, it’s Extensions only. So funky weird hybrid, no customized BaseApp (which wouldn’t be possible today anyway).
  • When we go AL (for product or customers), we only apply cloud-ready architecture.

That’s our focus today .. so not in the future, but today. Our product is the only reason why we implement C/AL today. I’m not ashamed it not being converted yet. It’s a big-ass product, and we want to take the opportunity to rethink everything carefully. “Hurry” never ended up in decent software anyway ;-)). When the product is finished, the only reason we will be on C/AL in our company would be legacy customers, while all new customers will be full AL.

Let’s dive in the above points a little bit more.

Rebuilding, no migration

Well, I know there is a txt2al tool, and there are very valid cases to use it. You won’t hear any bad word about it from my mouth. It’s just – looking at our situation – having +1000 hooks (not events) (while in extensions, I don’t want to use hooks anymore), new design patterns to be applied with extensions, … and a lot more reasons, we decided to do a rewrite with the big advantage we won’t have any legacy-stuff to solve. We will focus on one thing though – that’s trying to make sure we can upgrade data.

The good thing on this approach is that we can completely revise all functionality in terms of begin “cloud-ready”, like:

  • Remove all our .Net Interop
  • Remove all our file-based integrations (or any kind of file-based automation)
  • Focus on Service-based architecture (all funky stuff, provide (web) services for that – think “Azure Functions”)

Extensions only

Besides our product, we are currently into a 2-year development challenge for a customer, with heavily modified NAV, many integrations, .Net, file-based automation, .. and so on. An atypical heavy customized project. This project is being turned into a (set of) extension(s). I have no intention whatsoever to turn back to customizations, just because I think that my customers need to get what they expect: a way to upgrade, a way to be future-proof.

This project brings challenges for sure – but we’re getting there. I have full confidence we will be able to redo this heavy customized customer as a cloud-ready extension.

Cloud-ready architecture

I already kind of explained what I mean with “cloud ready” architecture. Basically, it comes down to being able to run it in the cloud. In essence, we need to apply the cloud-rules. And in terms of “rules” in AL development, we think of “compiler” and “code analysers”, right?

Well, what we have been applying for all our extension-projects, is very simple this:

  • In app.json: target = extension
    • So the compiler won’t enable anything that would not be able to run in the cloud as an extension, like .Net.
  • In settings.json: enable code analyzer “PerTenantExtension”, so also my code is analysed as such.

Makes sense? May be not for you, but after 9 months of development, +800 objects, it still does for us :-). Thanks to this, we have found multiple unexpected parts that we needed to refactor. “Working with files ” and “working with .Net” being the most obvious ones.

BaseApp in AL

Big news – Microsoft was able to convert their C/AL to AL! It has been in the news for quite some time, but now you have it – next release (Fall 2019), this is the only way Microsoft will distribute its codebase. And that’s a major thing. Even more – you will be able to do customizations.

Taking into account that in the future, we will NOT be able to do customizations, me personally, I don’t give one flying rats ass (sorry for my French). Cool for Microsoft to have a good conversion tool – but I won’t use it – may be to convert a set of objects (like reports) to copy, but I promise you now: I will never convert our product to AL. Just because – in my opinion – there is only one way forward. And that’s Extensions.

If you would go down the route to migrate your product/customers/… to AL, just imagine. How do you manage:

  • Support:
    • People are going to have to support those customers/products/databases
    • Now they have C/AL or Extensions
    • Then there is a 3rd scenario – a mix of default code (that you probably want to upgrade at some point), products and customizations in one codebase. In a new technology.
    • Imagine 300 customers, some have pure C/AL, some hybrid, some baseapp+customizations, some pure Extensions.
    • Good luck with that!
  • Maintenance / Upgradability:
    • Congrats, you are on the new version
    • But you haven’t progressed one singled bit.
    • Upgrades is still a pain
    • Maintenance is still a pain
    • No way you will be able to easily migrate to the cloud

I’m a bit intentionally negative here – but I think you know what I mean when I say that I will never go down the route of customizing the BaseApp (as AL). Today, full C/AL or full AL Extensions. No other way for me. The only thing we need to do is make sure our product is finished (as Extensions) by the next release.


One of the things to be “cloud ready” is to not use .Net. I get feedback from people that sometimes there is just no other way. And probably they are right. But in many (if not most) cases, you can avoid .Net. Vjeko and me did a session on NAVTechDays last year, were one of the topics was exactly that. I can strongly advise to watch that section here:

So, there you have it – probably some of you think it’s time to unfollow me, unsubscribe from this blog, … . I strongly hope I didn’t offend anyone – this was merely an attempt to justify my opinion on things. Nothing more. I will never judge anyone for going down a route that I wouldn’t go to. Probably it would just mean that you are more organized (or more courageous) than me ;-).