The landscape of Microsoft Dynamics 365 Business Central (BC) is undergoing a significant shift. Traditionally, customers leaned heavily on Microsoft Partners (Value Added Resellers) to navigate the complexities of ERP deployment. However, a growing trend sees businesses opting for self-implementation or “hybrid” models. This movement is driven by three primary factors: product maturity, the democratization of tools, and a desire for cost transparency.

The Low Code/NoCode Revolution

Modern Business Central is no longer the “black box” its predecessor, NAV, once was. The integration of Microsoft Copilot and the Power Platform has lowered the technical barrier to entry. Users can now use natural language to build workflows in Power Automate or create custom dashboards in Power BI without writing a single line of AL code.

Guided “Out-of-the-Box” Functionality

Microsoft has invested heavily in Assisted Setup wizards and “RapidStart” services. These tools guide users through the configuration of Chart of Accounts, VAT/Tax settings, and data migration from Excel. For many SMBs with standard processes, the “vanilla” version of BC is often sufficient, making expensive partner-led custom coding unnecessary.

	Partner-Led Implementation	Self-Implementation
Cost	High (Consulting fees, hourly rates)	Low (Internal resource time)
Speed	Structured, but dependent on partner availability	Highly agile; moves at the company’s pace
Customisation	Deep, code-heavy extensions	Process-focused, low-code/standard

Cost Control and Internal Expertise

ERP implementations are notorious for “scope creep,” leading to ballooning partner invoices. By taking the reins, companies gain total cost control and, more importantly, develop deep in-house expertise. Instead of calling a partner for every minor adjustment, internal teams who “built” the system can maintain it, leading to higher long-term agility and a more resilient digital culture.

While complex manufacturing or highly regulated industries still benefit from expert guidance, the “Citizen Implementer” is becoming the new standard for the modern SMB.

A challenging landscape for ISVs

While the shift toward self-implementation empowers the customer, it creates a challenging landscape for ISVs (Independent Software Vendors) the companies that build the specialized “add-on” apps found on Microsoft AppSource.

For an ISV, the move away from traditional Microsoft Partners is generally viewed with concern for several key reasons:

The Loss of a Skilled “Sales Force”

Historically, Microsoft Partners acted as the primary bridge between ISVs and customers. A partner would identify a gap in a client’s process and recommend a specific ISV solution (like a payroll or shipping app) as the fix. Without a partner acting as a trusted advisor, ISV apps become “lost in the noise” of AppSource, forcing vendors to spend significantly more on direct marketing and customer acquisition.

Implementation Failure and “Churn”

ISV solutions often require specific configuration to work correctly within a business’s unique environment.

• The Risk: When a customer implements a complex ISV app themselves without deep product knowledge, they are more likely to misconfigure it.
• The Result: If the app doesn’t work as expected due to poor setup, the customer blames the software, not their implementation method, leading to high churn rates (unsubscriptions).

Integration Complexity

While “vanilla” Business Central is easier to set up alone, integrating multiple third-party apps is where things get messy. Without a partner to oversee the technical architecture, customers may install competing apps that cause data conflicts. ISVs then find themselves in “finger pointing” matches with other vendors when a customer’s DIY ecosystem breaks down.

Ultimately, while ISVs want their products to be easy to use, they know that a professional implementation usually leads to a happier, long-term customer.

DIY clashes with traditions

It’s a fascinating (and somewhat tense) time in the Dynamics ecosystem as the “do-it-yourself” spirit clashes with the traditional consultancy model.

By cutting out the middleman, customers get agility and cost savings, but they definitely shoulder a higher risk of “spaghetti configurations” that ISVs then have to help untangle. It’s a classic trade off between upfront control and long-term stability.

Personally, I am seeing more and more implementations where the ISV is doing more than the VAR, because the ISV knows the processes that support its product much better than the VAR.
In addition, there is a high staff turnover at VARs, which means that knowledge of ISV apps is fading and cooperation is coming to a standstill.

How can this be reversed?