THE MILLION EURO PARADOX.
Twenty Years of Development. One Rather Uncomfortable Assessment.
After approximately twenty years of development and continued investment in its Dynamics NAV application, an organisation faced a consequential decision about its ERP future. The question was not simply whether Business Central could replace the existing application. It was what the business had built over those years, what continued to serve it well, and what it would be wise to leave behind.
An independent assessment offered an opportunity to examine those questions before choosing a transition approach. The application remained central to daily operations, but its long history and accumulated customisations made the choice of a future direction anything but straightforward. Before committing to a solution, the organisation needed a clearer picture of the application it actually had.
Beneath Twenty Years of Customisation.
Extensive code analysis revealed a concerning pattern of non-standard development practices, inconsistencies and questionable customisations, raising serious concerns about the application’s integrity, stability and long-term maintainability.
The concerns were not confined to the volume of bespoke development. They included modifications to standard application objects, duplicated processing logic and changes affecting business-critical processes. The findings also included dependencies on external .NET functionality. These findings required attention not because customisation is inherently undesirable, but because the way an application is changed determines how reliably it can be understood, maintained and developed further.
The assessment also identified non-standard SQL Server stored procedures used to modify NAV application data directly, bypassing established application logic and validation mechanisms. This approach, inconsistent with recommended NAV development practices, had resulted in identifiable data integrity issues within the affected records.
A second concern was the architecture that had accumulated around those changes. Dependencies between application objects, external components and business processes made apparently isolated work harder to evaluate. As knowledge of earlier decisions became fragmented, it grew more difficult to distinguish deliberate business requirements from workarounds, historical compromises and functionality whose original purpose was no longer clear.
Finally, inconsistent development practices, insufficient evidence of testing and application maintenance that had fallen behind compounded the difficulty. The issue was not whether every historical change had been wrong. It was whether the organisation could establish a reliable technical foundation for future decisions.
Individually, some of these shortcomings might have appeared manageable. Taken together, however, they revealed a more troubling picture: the cumulative burden of technical and operational shortcomings was beginning to outweigh the benefits of continued development.
The Illusion of Technical Mastery.
The Limits of Individual Knowledge
More than three decades of development have transformed NAV into an extraordinarily complex business application, incorporating generations of engineering decisions, interconnected processing logic and functionality spanning numerous business disciplines. No individual, regardless of experience, could reasonably be expected to retain every detail of that accumulated complexity. Understanding the application’s architecture and fundamental design principles is one thing; possessing an exhaustive knowledge of every processing sequence, dependency and subsequent correction is quite another. Genuine technical competence therefore lies not in claiming to know the entire application, but in recognising the limits of individual knowledge and knowing how to investigate beyond them. The source code, technical documentation, release notes and established development guidelines remain indispensable references whenever existing functionality is assessed or modified.
When an Innocent-Looking Change Casts a Long Shadow
An individual development request seldom reveals the full extent of the application functionality it may affect. What appears to be a straightforward correction, an additional condition or a relatively minor adjustment to existing business logic may produce exactly the expected result within the immediate scope of testing. Yet that same logic may participate in numerous other processes, transaction types and business scenarios, each carrying its own dependencies and assumptions. Without a thorough understanding of those relationships, supported by appropriate investigation and testing, a seemingly successful modification can introduce unintended consequences elsewhere in the application, sometimes remaining unnoticed until considerably later.
An Impressive Investment. A Rather Different Return.
Some of the organisation’s investment had undoubtedly supported useful functionality and business growth. But recurring operational difficulties, repeated support requests and familiar workarounds raised a more uncomfortable question: were underlying problems being resolved, or simply revisited? Continuing support activity alone could not answer it.
After years of substantial investment in an ERP application, protecting that investment requires more than maintaining the software itself. Where ongoing expenditure justifies it, employing an experienced NAV or Business Central technical consultant with a strong professional implementation background may help establish effective development governance and reduce dependence on external providers. Equally important, and often considerably more difficult to achieve, is maintaining a structured, accessible and continuously updated knowledge base connecting the organisation’s business processes and requirements with the functionality developed to support them. Such knowledge should remain an asset of the organisation, readily understandable and transferable to incoming employees or contractors, rather than disappearing whenever the people responsible for its development move on.
The Cost of Standing Still
An organisation may continue investing substantial sums in its ERP application without necessarily making meaningful progress towards improving it. Development requests are approved, support invoices are paid and individual problems are addressed as they arise. Yet without a coherent long-term direction, much of that expenditure can become devoted to preserving existing arrangements rather than improving the underlying application. In some organisations, maintaining the status quo gradually becomes more important than questioning whether the status quo is worth maintaining. The result is an uncomfortable contradiction: considerable investment, continuous technical activity and remarkably little evidence of lasting improvement.
Behind the invoices and accumulated customisations were employees repeatedly reporting familiar problems, enduring unsuccessful attempts at resolution and gradually losing confidence that meaningful improvements would ever arrive. The independent assessment therefore raised a question extending well beyond the application’s technical condition: how much of the organisation’s investment had delivered lasting business value, and how much had been absorbed by maintaining a system whose unresolved shortcomings had become part of everyday working life?
Professional Courtesy. An Expensive Thing to Lose.
Professional courtesy extends beyond responding to support requests and delivering the functionality a customer has asked for. It also means recognising when recurring difficulties, accumulated customisations or established working practices may be creating problems that the customer is not equipped to identify independently.
An experienced technical consultant may not have been engaged to conduct a comprehensive architectural assessment, but that should not prevent them from drawing attention to concerns encountered in the course of their work. Sometimes the most valuable contribution is not another development request completed, but an uncomfortable observation offered at the right moment, with the customer’s long-term interests in mind.
A Brighter Future. Doing It Right.
The purpose of an independent assessment was never simply to catalogue the shortcomings of an application that had already consumed years of investment, effort and patience. It was to understand what remained valuable, recognise what should no longer be carried forward and give the organisation a clearer direction for its next chapter. Whether that future involved Business Central or an entirely different ERP solution was ultimately less important than the opportunity it represented: a chance to leave behind years of recurring frustration and restore something that had gradually been lost along the way. The hope that, after all those years, the business might finally have an ERP solution that genuinely met its requirements, supported its people and offered the prospect of a brighter future.