Inside project “Madeira” part II | Extensions only?

By Mark Brummel – Founder of NAV Skills Masterclasses & Microsoft MVP since 2006

Yesterday I’ve started a series of blog posts about project “Madeira” where I  try to analyse the impact on the Dynamics NAV and ERP ecosystem.

As mentioned in this post I am very exited about project “Madeira” and I see the changes that we have to go through as a nessesairy bump to be able to have NAV in the next decades to come.

It will be a very disruptive change for the partner channel like moving from Native to SQL Database and moving from classic to role-tailored client and it is not going to be easy.

Extensions (Only??)

This blog post was primarily drafted a few weeks ago before project “Madeira” was announced as a result of a discussion we had with a few MVPs at the Dutch Dynamics Community event where Arend Jan Kauffmann did a (great) presentation about extensions in NAV 2016.

We know (as MVPs) that Microsoft sees Extensions as the future model for NAV to ship changes to customers. However, that does not mean that the model is mature enough to replace the traditional raw-source code modification model.

The last few days I’ve seen this image popup on Linked In and Twitter a few times


At the DDC event we had a major discussion which we settled with the thought that Microsoft will probably not be taking away the old model for a while.

This is not the case according to this slide and also not according to the keynote Marko Perisic was doing last week in German at the NAVUG Summit Europe event.

In the future, all modifications to NAV could and should be shipped as extensions, even if they are for one-off customers.


Let’s move into the blog post I’ve prepared.

The True impact of Dynamics NAV Extensions

Within the Microsoft Community we have had the opportunity to play with Extensions for about half a year now. There has been some blogging and together with Gunnar Gestsson I’ve hosted a webinar about it which you can view here.

I’ve also been teaching people on extensions in my Master Classes and have been getting a lot of feedback from across the globe, just returned from trainings in Thailand, Ukraine and Portugal.

Time to evaluate.

Extensions in NAV 2016 is a new mechanism of shipping changes to the product from one system to another, potentially replacing the FOB file. Since my Master Class is about Software Architecture in Dynamics NAV you might think this does not completely fit in.
But! Using extensions changes the way we think about the Dynamics NAV architecture. So it is important.

Based on Eventing

When Microsoft first talked about the (im)possibilities of extensions, my initial idea was that the limitation of not being able to modify the source code was the biggest change. With extensions we have to use events.

After the last six months and talking about it with many people I think there are bigger challenges with extensions than having to use events.

Dynamics NAV 2009 – Introducing the Three-Tier model

It is now, give or take a few months, a decade ago since I first got my hands on a prototype of what would eventually become NAV2009, introducing pages, webservices, RDLC and all the things we take for granted now.

During this time, there were some discussions on the impact of the new technology on the way we develop. I remember two particular topics.

1. No code on forms/pages

Microsoft raised the idea to discontinue the possibility to program on pages. The reasoning behind this was not completely clear to me, but I guess it would force people to structure their code in a better way and it would be easier for Microsoft since there would not be any code executed based on what happens in the client.

2. Compile all objects before shipping

The second issue we had during the prototype period was to compile all objects in order to have the generated C# code in synch. This was raised at one of the early Directions events and caused quite some unhappiness in the ecosystem.

Both issues were fixed by Microsoft because the impact on the way partners do development would simply be too big. Eventually Rapid Development in NAV even became easier since changing the objects is now automatically picked up while in the classic client users had to close and log in again while losing the personalization settings in the zup file.

For 10 years, life was good. The three tier model kept on being improved and especially the performance enhancements where just stunning. We can now easily implement Dynamics NAV with 250+ concurrent users which used to be Dynamics AX territory.


Now, a decade later, with extensions we are at the new start. But the impact might be a lot bigger than what most partners are thinking about.

Let’s look at the two components of extensions why I think they will force partners to reconsider their strategy, or why the model might even fail for the current ecosystem.

Customizing customizations.

Yes, that sounds interesting right? What do I mean with customizing customizations. Well, it is actually quite easy. NAV Partners who have been in business for a while have all developed “standard” solutions which many sell as verticals using the CfMD program. But the nature of NAV customers is that they buy the software to be modified. Many partners have a hard time finding two databases that are exactly the same.

I’m not saying they don’t exist, I know that there are partners who really have standard verticals, but this is not the majority of the solutions out there.

When you ship a solution that your customer wants to have customized, extensions are not a real option. You cannot change the code anymore once it is shipped as an extension. You could surely do it, but it takes away the whole idea of extensions being easy to upgrade since you will end up merging customizations anyway.

A solution to this problem might be to build extensions on top of extensions. But let’s be honest, that would take away the whole idea of Rapid Development and simplicity of the implementation.


One thing I admire at Microsoft is the way they implemented rollup updates. They now have one “release” each month which is tested automatically. Most partners are not there. Especially when you implement Dynamics NAV at customers that require modifications.
We often develop agile in sprints with prototyping but when it comes to testing the partners and customers are poor. Hence making several hotfixes after a release is not uncommon.

Making a hotfix for an extension is not actually easy. You have to create a full release of your entire solution and role this out using PowerShell. This is more or less the same as the issue we had 10 years ago when we thought we had to compile the whole application before shipping. Making a quick fob is no longer an option with extensions.


When we ship schema changes with fob files the data we have in customized fields remain. This is not the case with extensions.

If you ship an extension the old data is always “deleted”. Well not completely, it is archived. You have to write code that handles the upgrade, even if you have not changed anything.

Sure, the solution is to write some generic code using RecordRef and FieldRef but how does that perform if we have a schemachange on a table with 15GB of data which is not that uncommon with Dynamics NAV systems. This is a nightmare!

The upgrade story you have to run each version of the extension is in my opinion the BIGGEST pitfall of the concept besides hotfixing and customizing customizations.

So now what?

Many partners I talk to come to the conclusion that extensions are not usable for their business model and this is true.

Microsoft is targeting a new type of partner with extensions. Partners who have true repeatable solutions that are used by companies that have systems that are not that large and don’t require big changes on top of their system.

The impact of this new journey will be a lot bigger than the impact of moving from classic to role tailored. Many partners will have to decide how and if they want to change their business model, including me.

Design Patterns

This new way of software development requires a more professional attitude towards consistency in your development teams and also a new way of looking at the user interface. During my Master Class I spend a lot of time on building a more intuitive user interface and making your solutions easier to maintain.

The value of this had proven to be successful both in traditional NAV development and repeatable NAV development.


10 thoughts on “Inside project “Madeira” part II | Extensions only?

  1. My concern about the Extensions is when we take over a customer who’s previous NAV Partner has used Extensions for ‘normal’ client specific customisations, it will be difficult to support or modify these changes unless the customer has the original objects somewhere.

    For example, say that a customer wanted a change in the Sales Release process which, amongst other changes, checked to make sure that there was a G/L line for a delivery charge on every Sales Order. The original partner added this change, using events, and a few other changes as well and used extensions to publish and install the modification.

    Now we come along and due to the customer moving away from the original partner (or the original partner going bust), we now take over supporting them. We do not have the original objects as the original partner did all development on their own server before publishing and the customer doesn’t have a copy. The customer now wants the G/L Line check removed from the release process as they have certain customers who they don’t want to charge a delivery to.

    The problems I foresee are as follows:
    1) We cannot take this modification out without removing the whole publication.
    2) How do we know which publication contains the original modification? There could be multiple publications all including the Release Codeunit
    3) When we take out this publication, we could be taking out 100’s of other modifications which we don’t know about.

    I can see Extensions being used by NAV partners almost as a hold on the customer to say ‘You can go to someone else but they cannot support these changes….’

    Is this correct or have I (hopefully) missed something?




    1. Chris, I completely agree with you. Did you contact Microsoft about this?

      Customers should be made aware that in one-off customizations that they demand a copy of the code alongside the extension.


      1. We need some kind of method “Extract-NAVApp” to extract the NAVX file from the service tier, such that we can inspect the delta files.


  2. Another important question I have is, will Microsoft itself use extension to differentiate the product? Now we have strongly localized versions of NAV, where I don’t see how extension would work; codeunit 80 in local versions is not just adding something to codeunit 80 in W1, it is often doing different things, including posting different transactions. So if we have to rely on extension to roll-out an international project where a global application is not possible or not desired, how would we do it?

    Liked by 1 person

    1. Until we can program on top of an extension (i.e. extension is open source) the localisations IMHO cannot be an extension. I don’t see that happening in the next release.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s