Technical debt does not sit on the surface where anyone can see it. It is the base layer: everything that fell early, got skied over, refroze, and now quietly holds up the whole mountain. In a Business Central environment it is buried in custom extensions, legacy NAV customisations, reports, integrations, workflows, Power Automate flows, data structures, unused functionality, missing documentation and the manual workarounds people invented the week something stopped working and never took back out.
The traditional approach is to assemble a team, hand out shovels and dig by hand, one column at a time. AI can make that dramatically faster — not by replacing the judgement, but by removing the reading.
What is actually buried under there?
It is not simply old code. Old code that works is just a well-worn groomer. Technical debt is the accumulated cost of decisions that make the ERP harder to change, maintain, secure, integrate or upgrade.
A customisation is not automatically debt. One that delivers essential business value has earned its lift ticket and can ride all season. The problem is the customisation that:
- No longer provides meaningful value
- Duplicates standard Business Central functionality
- Creates upgrade complexity
- Depends on specialised knowledge held by one person
- Breaks integrations
- Has poor or absent documentation
- Exists because that is how it has always been done
Map the mountain before you grade it
There is no conditions report for terrain nobody has mapped. The first step is knowing what exists, and the inputs are unglamorous: extensions, objects, AL code, reports, pages, tables, APIs, integrations, Power Automate flows, job queues, scheduled processes, custom fields, documentation and usage telemetry.
AI can then sort what it finds into piles:
| Component | Classification | What it means |
|---|---|---|
| Custom pricing extension | Critical | Keep and document |
| Old report | Investigate | Check usage before deciding |
| Duplicate integration | Replace | Two paths doing one job |
| Legacy field | Investigate | May carry historical meaning |
| Unused workflow | Remove | No execution in the sample period |
| Standard functionality duplicate | Modernize | Base product caught up |
This does not replace technical review. It accelerates it, and it makes the review consistent across thousands of components instead of dependent on which reviewer happened to be on shift the morning somebody asked.
The groomer already did this run
The biggest single opportunity is identifying customisations that are no longer necessary because the base product caught up while nobody was watching. Somebody bootpacked that line for three weeks in a previous release, and Microsoft has since run a chairlift over it. For each one, the questions are the same:
- What does this customisation do?
- Why was it created?
- Is it still being used?
- Does Business Central now provide equivalent functionality?
- Does an AppSource solution provide it?
- Could configuration replace it?
- Should it be rewritten?
- Should it be removed?
Digging a pit in the AL code
Where source is available, this is where AI properly earns its keep. It can identify complex procedures, repeated logic, hard-coded values, likely performance concerns, dependencies, deprecated patterns, duplicate functionality and missing documentation — the weak layers you only ever find by cutting into the pack and looking.
It can also summarise. Reading a 2,000-line extension end to end just to work out what it is for is thirty minutes of sidestepping before you are allowed anywhere near the drop-in. An architect can ask for the shape of it instead:
That is a dramatically better starting point than a blank page and a hopeful message to whoever is left from the original project.
The cat tracks nobody bothered to map
Integration debt is the one everybody skis straight past. Environments quietly accumulate connections nobody fully understands, often maintained by whoever built them — an unmarked traverse with exactly one person who still knows where it starts.
AI can help build the catalogue — system, direction, method, frequency, purpose, owner, failure handling, risk — repeated for every integration. Do that once and the architecture stops being folklore and starts being a trail map.
Where the trail map lies to you
AI can compare what the system actually does against what the documentation claims it does. The gap between those two is where people get hurt, and it opens widest during staff transitions, acquisitions, ERP migrations, cloud migrations and support handovers.
A system should not depend on one employee remembering why a customisation exists. That is not documentation. That is a local who knows where the rocks are — and locals take other jobs.
Grade every run and post it at the top
Ski areas do not hold a debate about whether a run is frightening. They grade it, put a sign at the top and let people choose. Do the same here. Each component can be scored on business value, usage, complexity, maintenance effort, security risk, upgrade impact, integration dependency and documentation quality.
AI reads the terrain. Patrol still makes the call.
AI will occasionally read the slope wrong. It may infer the wrong reason for a customisation, misread business rules, miss hidden dependencies, or cheerfully recommend removing something that looks unused and is operationally critical one week a year.
So put the division of responsibility on the board before anyone drops in: AI identifies candidates. Architects validate them. Business owners determine value. Nobody deletes anything on a hunch and a dashboard.
The same lap, every season
What you get at the bottom
The goal is not eliminating every customisation. It is knowing which ones are earning their lift ticket.
A healthy ERP environment is not the one with zero customisation. It is the one where every significant customisation has a reason to exist that somebody can still say out loud, without checking their notes. Once you know that, you can decide what to build with.
