Every business moving to Business Central has a list of things the old system did "just for us". Most of them should not survive the move. How to run the fit-gap honestly, the "we have always done it this way" trap, and the three questions that decide what gets rebuilt.
Somewhere in the Analysis phase, someone produces the list. It is the things the old system did that were built specially: the report with the extra column, the posting routine that does something clever with carriage, the field on the sales order that drives a label, the twenty-year-old modification that nobody remembers the reason for but everyone is sure is essential. The list is usually long, and the request is always the same: can Business Central do all of this?
It can. It should not. Most of that list should not come with you, and the fit-gap is where you decide which parts do.
Customisations accumulate for reasons that made sense at the time and no longer apply. The old system could not do something standard, so it was built; the new one does it out of the box. A manager wanted a report a particular way in 2011 and has since left. A process was designed around a limitation of the software, then the limitation became the process. Every one of these feels essential because it is how things are done now, and "we have always done it this way" is the most expensive sentence in an ERP project.
The cost is not just the build. Every extension is tested twice a year when Microsoft releases, maintained when the business changes, documented so the next consultant can understand it, and carried in every future upgrade. A customisation is a subscription you pay in effort forever. Ten of them is a maintenance burden; fifty is a project that never ends, and it is how the organisations in our piece on failed projects spent years bending software to the old way.
Every item on the list goes through the same three questions, in order, with the business owner in the room and the answer written down:
What survives is usually five to ten items, not fifty. They are documented, estimated and built as proper extensions that survive updates. Everything else is retired, and the reason is written down so that when someone asks in eighteen months, there is an answer.
The ones that are genuinely yours: the pricing logic that wins you contracts, the label format your largest customer mandates, the traceability your regulator inspects, the integration with the machine on the shop floor, the KPI the board runs the business on. Those are the extensions that earn their place, and they are built properly: as AL extensions against published events, with unit tests, with documentation, in your own code repository. Our development page has more on how.
The fit-gap is a workshop, not an email. The business owner, the super user and the consultant, in front of a sandbox, going through the list. When the answer is "standard does it", the consultant shows it there and then. When the answer is "change the process", the owner decides, and the project manager records it as a decision rather than reopening it in UAT. When it is a genuine gap, it is costed on the spot in days, so the decision is made with the number visible.
Done this way the list shrinks, the project gets cheaper and shorter, and the business ends up on standard software it can upgrade twice a year without fear. If your list is long and nobody is pushing back on it, a health check is a cheap way to find out which items are real.
