A manufacturer came to us mid-build with a hundred and forty customizations on the backlog and a timeline that had stopped meaning anything. We sat down and went through the list with them, line by line, and the picture that emerged was one we have seen many times. Roughly half of the items were not gaps at all; they were either standard functionality the team had never found, or requirements written as "make it work like our old system" with no real business need behind them. About a third were genuine needs that a change in process would have met without a single line of code. The truly unavoidable gaps, the requirements the platform honestly could not meet through configuration or a reasonable process change, numbered under twenty. They were building roughly seven times more customization than their requirements actually justified, and every one of those customizations was going to follow them into every future upgrade.
This is what happens when nobody runs a real fit-gap analysis. Fit-gap is the discipline of taking each requirement and deciding, deliberately, how it ought to be met, and its central job is to stop the answer from quietly defaulting to "build it." When a project ends up over-customized, it is almost never because the requirements demanded it. It is because no one made the configure-over-customize principle real at the level of individual requirements, one at a time, with someone whose job was to push back.
There are three resolutions, not two
The first thing fit-gap fixes is the false choice. Teams tend to look at each requirement and see "configure it or build it," when in fact there are three ways to resolve it, and the one they miss is usually the cheapest. A requirement is a fit when standard configuration inside the out-of-the-box platform meets it with no code, and this should be the large majority. It is a process change when the platform does something equivalent but different from how the business works today, and the right answer is to adapt the process to the platform rather than bend the platform to the process. And it is a genuine gap only when the platform truly cannot meet it through configuration or a reasonable process change, which should leave you with a small minority.
Collapsing those three into two is exactly how the gap pile inflates. Every requirement that could have been a process change quietly becomes a customization instead, because "change how we work" was never on the table as an option. The third of the manufacturer's list that a process change would have solved is the direct, measurable cost of leaving that option out.
Challenge a gap before you build it
The highest-leverage habit in fit-gap is treating a declared gap as a hypothesis to be tested rather than a fact to be implemented, because most first-pass gaps fall into two categories that turn out not to be gaps at all. The first is requirements stated as implementations. "The order entry screen must look like our legacy system" is not a business requirement; it is a solution someone decided on in advance. The business requirement underneath it is something like "users can enter orders efficiently," and the standard screen usually meets that perfectly well. Strip the requirement back to the actual need and the gap often evaporates, and a large share of the manufacturer's list was precisely this, the old system's behavior written up as a requirement.
The second category is functionality the team simply has not found. F&O is enormous, and a surprising number of "gaps" are standard features that nobody located. So before anyone builds, the question is always whether there is a standard way to do this, and the answer is yes more often than teams expect. A declared gap that turns out to be a configuration is the cheapest win available on the whole project. Only after a gap has survived both of those challenges, once it is a real need and the platform genuinely cannot meet it through configuration or reasonable process change, does it earn a customization. Running every gap through that gate is what takes a list of a hundred and forty down to under twenty.
Why customization is the expensive answer
The configure-over-customize principle is not about purity, and it is not about avoiding code for its own sake. It is about the total cost of a customization across the life of the system, and the largest part of that cost is upgrades. A configuration carries forward cleanly when the platform updates. A customization does not get that for free; it has to be maintained against every platform change, retested on every update, and occasionally rebuilt outright when the platform shifts underneath it.
A system with twenty well-chosen customizations has upgrades that are routine events you schedule without dread. A system with a hundred and forty has upgrades that are projects in their own right, and eventually it has the upgrade that turns into a re-implementation, because the accumulated customization debt finally costs more than starting over. This is the same lesson that makes us treat an AX 2012 to F&O move as a redesign rather than a re-overlay, which we wrote about in approaching that upgrade as a redesign: the customization you did not actually need is debt you keep paying at every upgrade, forever. So the real fit-gap question is never "can we build this," because you almost always can. It is "is this worth carrying through every future upgrade," and for most requirements the honest answer is no.
Run fit-gap as a living discipline
The other way fit-gap fails is when it is treated as a single workshop at the start, after which everything is considered decided. In reality, new requirements and new gaps keep surfacing all through the build, and each one arrives at the same fork. If the fit, process-change, or gap decision only ever happened at kickoff, then every gap discovered afterward defaults to customization, because the discipline that would have challenged it is no longer running.
Keeping it alive does not take much, but it has to be deliberate. Every new requirement gets the three-way decision, with the gap path gated by the same two challenges as before. Every declared gap records why it is a gap, what business need it serves, and why neither configuration nor process change can meet it, so the justification is on the record and someone can review it. And the customization count gets watched as a health metric, because a number that is quietly climbing is the earliest signal that the project is drifting back toward building everything by default.
What fit-gap leaves you with
A D365 implementation with real fit-gap discipline ends up with a requirements log where each item has been resolved as a fit, a process change, or a gap, deliberately and on the record rather than by reflex. The gap list that remains has survived the two challenges, so it is not full of implementations in disguise or standard functionality nobody found, and the genuine gap rate is low as a result. The customizations that did make the cut are justified by a documented business need and an accepted upgrade cost, not waved through because building felt easier. The process changes are captured and owned by someone, because adapting the business to the platform only works if a person actually drives the change management behind it. The fit-gap log stays alive, still making the decision for requirements that surface during the build. And the customization count stays low enough that future upgrades remain events rather than re-implementations.
The discipline lives entirely in the decision, made deliberately, for every requirement, with the burden of proof placed on customization rather than against it. Configure-over-customize only becomes a real principle when something is actively stopping the gap pile from filling up with requirements that were never gaps in the first place.
