Inside project “Madeira” | Why extensions will fail to upgrade too…

If there is one thing I learned from my previous blog post is that a catchy title works. Eventhough it’s early August I have had a lot of emails and comments on my last blog “Dynamics NAV is Dead! Long live Dynamics NAV!“.

Why? People seem to sometimes only read the title, or half the title. Someone sent me a message on LinkedIn asking what to do now that NAV is dead.

NAV is far from dead and what I wanted to “achieve” with my blog is to alert people that NAV is changing, like James Crowter is mentioning in his last blog. “The answer is extensions, now what’s the question”.

Microsoft seems to be thinking that Extensions are the golden bullet to all the challenges we have with NAV. This idea is wrong.

What are extensions again?

Extensions are a new technology based on two other relatively new ideas namely Delta files and Events. Delta files were introduced in NAV2013R2 (backported from NAV2015) and Events are introduced in NAV2016 inspired on Hooks.

The reasoning behind Extensions is ease of upgrade. For the last couple of years Microsoft has been hearing complaints from customers that upgrading NAV is hard and sometimes the ROI is negative.

Why is that? Because we have to move from classic to role trailored and forms have to be transformed to pages, reports to RDLC and all the users have to learn a new UI.

How is extensions going to make that easier? As if we are going to make this journey again? I hope not!


Let me give you four reasons why extensions are not going to make upgrade easier.

Scenario 1. – Changes to Document Approval

A user has requested a change to document approvals. Some fields were added to table 453 – Approval Code and they are shipped as an extension.

Microsoft releases NAV 2016 and the customer wants to upgrade. They expect an easy upgrade since they listened to the marketing story and had their partners ship the solution as an extension.

When they try to run the upgrade they get an error message “Table 453” no longer exist and the extension has to be refactored.

Scenario 2. – Workflow

A user is running NAV 2015 with Workflow as an add-on. Let’s asume that this is running as an extension using the new rules of prefixing. Now the customer wants to upgrade.

The upgrade runs fine because there are no conflicts because of the prefixing. Now the customer starts using NAV2016 but they find out NAV2016 has workflow out of the box. Now they have two workflow solutions.

Scenario 3. – Attributes

A user wants to upgrade from NAV2016 to NAV2017. Right now they have a solution that allows them to have item attributes and this is an extension.

In NAV 2017 we get them in standard NAV. I think you get where I want to go

Scenario 4. – New Client

This scenario is more science fiction than the first 3, but the main reason customers are complaining about upgrades is moving from classic to RTC. Let’s say we make that move again? Let’s asume Microsoft decides to discontinue RDLC and move to Word only. Just an example here, no announcement.

If I have extensions using RDLC they would no longer work on the new version.

So now what?

I don’t know. All I want to say is don’t drink to much of the marketing cool-aid. If we want to make upgrades easier all we need is Delta files and good education. We will always have conflicts. Who cares, as long as the conflict is easy to solve. This is why we have Hooks. We don’t need Events.

Extensions will work with Dynamics 365

The way Dynamics 365 is shipping will make extensions work. It’s a long story and worth another blog but the combination works. Problem is that Dynamics 365 is serving a different kind of customer. Not the type of customer with a request for bespoke software but a customer that wants an easy cloud solution that has some vertical specific capabilities.

Extensions are counter productive

When used instead of fobs for traditional NAV development Extensions are counter productive for three reasons

  1. They require longer upgrade time with each version because of the way they are engineered.
  2. Once deployed in a production database they cannot be changed. Each change require a data upgrade.
  3. They are not open code. The source code is protected which disables customers to move from one partner to another.

Extensions, Extensions, and more Extensions

One thing I noticed when looking at the NAVTechDays agenda is that there are two sessions about Office 365 and two sessions about Extensions. To me that looks a little overkill since NAVTechDays was always focussed also on traditional NAV and not so much influenced by the Microsoft marketing machine.

When asked Luc van Dyck replied the reasoning behind this was Microsoft and the fact that he was told that in the future, customisations should be shipped as Extensions.

Well, I sure hope this will not be the case.