The BC Implementation Opportunity Nobody Is Talking About Yet
Every BC implementation partner knows the pattern: margin absorbed, timelines extended, client expectations managed downward. The opportunity to change that is arriving, and most of the ecosystem has not yet looked up from the current process long enough to see it.
There is a process at the centre of every Business Central implementation that has remained essentially unchanged since the platform was first deployed at scale. A client describes a business requirement. A functional consultant interprets it. A developer translates the interpretation into AL code. Someone tests the result manually. Feedback comes back. The cycle repeats.
The number of tools available to support this process has grown considerably. The process itself has not.
The requirement-to-production cycle in BC customisation is still, at its core, a handmade process. Each extension is built from scratch or adapted from a prior project. Each test is run by a person following a test script. Each deployment is managed by a developer who understands the specific configuration of this client’s BC environment.
This is not a criticism of the people doing the work. BC implementation teams are, in many cases, operating at the limit of what the current process allows. The problem is the process, and the process has structural characteristics that make it resistant to improvement within its existing design.
Why the cycle is so hard to compress
The requirement-to-production cycle in BC is long for reasons that are interconnected and mutually reinforcing.
The first is the translation problem. Business requirements are expressed in operational language. The person describing the requirement understands what the business needs, but not necessarily how BC’s data model, permission architecture, or extension framework will accommodate it. The developer understands the implementation constraints, but not necessarily the business context that makes one approach preferable to another. The functional consultant sits between them, translating in both directions. This translation layer adds time, introduces interpretation errors, and creates a feedback loop that is difficult to short-circuit.
The second is the testing problem. Manual testing of BC customisations is time-consuming, inconsistent, and incomplete. Test scripts capture the scenarios the tester anticipates. They do not capture the scenarios the tester did not think to test, which are precisely the scenarios most likely to surface as production issues after go-live. Automated testing in BC environments exists but is not yet standard practice across the partner ecosystem, and implementing it adds a layer of upfront investment that many projects cannot absorb.
The third is the knowledge problem. Every BC implementation accumulates environment-specific knowledge, configuration decisions made early in the project, integrations added at different points, customisations that interact with each other in ways that are not always fully documented. This knowledge lives primarily in the heads of the people who built the system. When those people are not available, or when a new requirement touches a part of the environment they did not build, the investigation work required before a new extension can be safely developed adds time that the project timeline did not anticipate.
What this costs
The cost of the handmade build process is distributed across three places.
Partners absorb it in margin. Projects that were scoped on the assumption of a linear, well-understood build process encounter translation delays, testing rework, and knowledge investigation work that was not in the estimate. The additional effort comes out of the project margin rather than the client’s budget, because raising a change request for work that should have been part of the original scope is a conversation nobody wants to have.
Clients absorb it in timeline. The requirement that was described in week three of the project is tested in week eleven. By week eleven, the business context has shifted. The person who described the requirement has moved to a different role. The urgency that justified the customisation has either intensified or resolved without the system’s involvement.
The relationship absorbs it in trust. A client who expected a three-month implementation and experienced a five-month one, with a final result that only partially matches what was described, does not approach the next project with the same confidence. The gap between what was promised and what was delivered is the gap where partner-client relationships erode.
Why this is a structural problem, not an execution problem
The instinctive response to the build problem is to improve execution within the existing process. Better project management. Better requirements documentation. More experienced developers. More thorough testing.
These improvements help at the margin. They do not change the structural characteristics of the process. The translation layer is still there. The manual testing is still there. The environment-specific knowledge is still concentrated in individuals rather than systematically captured.
The build problem in Business Central is not a problem that can be solved by doing the same thing better. It requires a different approach to how requirements become extensions, how extensions are tested, and how environment knowledge is captured and reused.
That different approach is beginning to arrive in the Dynamics ecosystem. Microsoft’s announcement of Project MIA at DynamicsMinds in May 2026, aimed initially at F&SCM partners, signals that the ecosystem’s direction of travel is toward AI-assisted implementation. What that means for BC, and on what timeline, has not yet been confirmed. What is clear is that the build problem is recognised at the highest level of the ecosystem, and that the current process is not the destination.
The partners and clients who understand the structural nature of the problem now will be better positioned to evaluate and adopt what comes next. The ones who attribute it to execution will keep trying to fix the wrong thing.
Let’s chat further.
"*" indicates required fields
