In the last year I’m seeing lots of existing Dynamics 365 Business Central on-premises customers deciding to move their ERP to the cloud. What I’m observing is that the trend of existing on-premises customers choosing the cloud is growing a lot compared to the previous 2 years for example, and this is the sign that finally the new generation of ERP customers is trusting the cloud and is understanding the countless advantages that this transition entails for their software platform.
This is absolutely a positive sign, but that’s not all…
I’m also observing a negative aspect: lots of customers that want to migrate to the cloud are literally blocked on this jump by some partner’s implementations tightly coupled to the on-premises world.
This could be acceptable if there’s a cloud migation project in place and customer and partner agree to change the architecture of some customizations in order to make them cloud-compliant in a SHORT defined time-frame. But if a partner says to a customer that its ERP system cannot be moved absolutely to the cloud because its implementations are not cloud-compliant OR if a partner started a project one or two years ago by creating customizations that are not cloud-compliant, then for me there’s a big problem!
In the last 3 months (so I’m considering a not so long period) I was contacted by at least 12 customers handled by partners with the previously mentioned problems: their transition to the cloud was blocked (and is actually blocked) because:
- The partner created integrations with external systems in AL by using DotNet objects in AL code.
- The partner created direct integrations between Dynamics 365 Business Central and external systems (AL writing into the database of the external system and the external system writing data into Business Central SQL tables).
- The partner is not able or ready to change this type of integration.
I saw also partners giving crazy answers to customers that are in this situation, like “your external system is an on-premises system, so also Dynamics 365 Business Central must be deployed on-premises” or “only with Dynamics 365 Business Central on-premises you can integrate on-premises systems“.
Dear customer, if a partner gives you a response like this, run away!
My impression is that lots of Dynamics 365 Business Central partners don’t know the concept of “decoupling systems”. Decoupling is taking a functionality or set of functionalities out of an existing application, and making it completely independent in a way that it can act and be developed on its own. Decoupling is also considered as a practice for reducing operational dependencies across different systems.
In the old days (the mainframe era!) systems were designed as large monolithic boxes where all functionalities, services and data were part of the same system.
The second generation of software design is where the focus was on efficiency and re-usability. Applications were developed in layers separating presentation, functionalities, integrations and data. Each layer has its own autonomy in its overall design and construction.
In a modern software design, when you have two systems to integtate and that two systems are independent and can run everywhere, having a point-to-point integration is a worst practice.
Strictly speaking about the common Dynamics 365 Business Central scenarios that I often see are the following:
Partners create integrations with an external SQL Server database by using .NET integration into AL (Microsoft.Data.SqlClient component) and partners interact with Oracle databases by using Oracle objects from AL code.
In 2024 there’s no reason to do things like these (just extracted some samples from cases I’ve received):
And then creating tons of lines of AL code calling direct SQL commands:
Or referencing Oracle Data Access objects (DotNet objects in AL) and calling them from AL to interact with Oracle databases:
The previous 3 code extracts are BAD THINGS!! Run away from that!
These are bad things because:
- They create a point-to-point connection between Business Central and the external database.
- They’re not cloud-compliant.
- They force to have an extension with Target = OnPrem.
Dear partner/customer: if in 2024 you have this line in your extension’s app.json file, there’s something wrong:
I’m pushing inside Microsoft from years to definitely removing “target”: “OnPrem” in extensions, but unfortunately this option is still here today. I think there are times when drastic decisions have to be made to have evolution, and this is one of them.
In 2024 a good partner cannot stop a Dynamics 365 Business Central migration to the cloud just because their extensions are not cloud-compatible. Even worse if the reason that blocks a customer migration to the cloud is the partner’s inability to make their applications cloud-compatible.
The above integration scenarios can easily be transformed into a decoupled and cloud-compatible solution by placing a middle tier between Dynamics 365 Business Central and the external system:
A good partner need to know how to create a decoupled solution like in the above schema. If not able to do that, contact someone able to do that… but DO THAT!!
Now my personal message to Dynamics 365 Business Central on-premises CUSTOMERS reading this post:
- Please check yout integration solutions with your Business Central partner. Always ask for implementation details.
- Please pretend to have cloud-compatible customizations.
- Please pretend to have decoupling between systems.
- Don’t trust partners saying you that you cannot be moved to the cloud.
- If a partner today creates customizations for you by integrating systems in the way described above, this is not the right partner for you. Greet him cheerfully and go to those who can really support you in a modern way.
Remember to always monitor the work your partner is doing on your system…
And for you, Dynamics 365 Business Central PARTNERS: let’s not discredit the system by saying untrue things. There are no technological barriers today that could block a move to the cloud. At customers you must tell the truth and the inability of the individuals must not be masked as a limit in the platform, which has absolutely no limits in this sense today.
Stefano Demiliani 
I am totaly agree with you, what about customers that already have invest in hardware and software and had like 330 full users, the cost to move to the cloud is another cost for the company.
LikeLike
That’s another topic. Every customer here can do the right evaluation (don’t forget that cloud costs also cover the infrastructure management).
In the post I’m only talking about blockers due to implementations. In 2024 there are no blockers related to code and customers need to know that.
LikeLike
Tight coupling is bad, right?
Yet every time you advocate to move to the cloud and integrate with other cloud services you in fact advocate for creating a tight coupling – with ONE vendor and their own solutions. Where each CPU cycle is charged. Every byte of storage is charged, and every byte transferred to and from the system is charged.
But this is OK somehow
LikeLike
In my opinion, moving to the cloud is a choice of trusting a cloud provider, not related to coupling applications (topic of this post).
Coupling/decoupling application is a technical aspect valid for onprem or cloud apps. Seeing barriers on moving to the cloud because an app is tightly coupled with another is something crazy nowadays.
LikeLike
Trust and coupling are different matters indeed.
You need to trust the vendor in order to make a shift to the cloud – because once you are there you are over the barrel.
As to the coupling – a technical aspect then: when you move to the cloud and engage with some other Azure services – can you easily go back? Can you move to another cloud provider, or back to onPrem?.
The samples you posted are bad ones indeed. However, in my opinion, what makes them (so) bad is implementation. Lack of clearly defined contact point, lack of an interface, dependency on some particular stored procedure – but not exactly the fact that a direct SQL connection is used.
The direct SQL connection is not the best idea, to put it mildly, but, equipped with some extra stuff, (like user-accessible configuration of connection strings, queried table /procedure etc, isolating the code to a module that can be enabled or disabled by the user or system admin) could shift it off the ‘tightly coupled’ category of solutions.
By the way – the fact that you said ‘Don’t trust your partners’ and advocated for denying users the onPrem options is beyond me.
LikeLike
Great article. I cannot believe we are still here where we have in all the tools in the cloud to allow us to decouple dependencies. Unfortunately the only loser is the customer at this stage. Partners need to assist in moving their customers forward and not hold them back.
LikeLiked by 1 person
“Dear partner/customer: if in 2024 you have this line in your extension’s app.json file, there’s something wrong”
Apparently using inside your solution a regular expressions implementation provided by the very Microsoft is “something wrong”.
LikeLike
I don’t see how the suggested solution with a decoupled solution in between BC and Oracle will work ? Yes, it will no require the “OnPrem” flag and it will be cloud-compliant. The post is not revealing the key fact that BC SaaS do not provide a direct SQL access. Hence as long as SQL is used as technology the solution will not be BC SaaS compliant, no matter how you build it.
LikeLike
What? 😵 direct SQL access is possible on-prem but direct SQL access is also the opposite of a well-architected distributed and scalable solution.
LikeLike
It’s called web services. Expose those tables as web services, I’m sure there are other ways around.
LikeLike
The answer is simple: cost and profit.
For partners is not profitable moving all customisations to be cloud compliant as customer wouldn’t pay, required resources and knowledge from partner… So they just say it has to be on prem.
LikeLike