That pause is the subject. It is the moment a system stops being an asset the business directs and becomes a constraint the business negotiates with. It arrives years after the decisions that caused it, and it is almost always diagnosed as a resourcing problem.
The real cost of technical debt is hard to see because it is rarely approved as a decision. There is seldom a meeting where somebody proposes making the system permanently harder to change, and almost never a budget line for it. It accumulates the way most expensive things do — one reasonable exception at a time, each approved by a competent person under deadline pressure.
The Interest Is Charged in Time, Not Money
The borrowing metaphor gets one thing right. You do pay interest, continuously, and the payment is not optional.
Where it misleads is the principal. Financial debt has a payoff figure. A heavily customised ERP often does not, because nobody is certain what all the customisations do any more and the people who wrote them have moved on. That is less like debt and more like a lien.
And because the interest is charged in time rather than cash, it never triggers a review. An invoice gets scrutinised. A slower quarter does not. The payment shows up as change lead time: the enhancement that took a fortnight in year one can take three or four times as long by year four, and the team has not got worse. Every change now has to be reconciled against every prior exception. The system did not get bigger. It got more entangled.
How It Accumulates
The pattern is worth naming, because it is reasonable at every step.
A requirement arrives that the platform does not handle natively. Standard configuration covers most of it. Covering the remainder requires either changing how the business works or building something custom. Changing how the business works needs agreement from people who are not in the room. Building something custom needs a developer who already is.
So the custom object gets built. It works. It is not documented, because it is small and obvious to whoever wrote it. Repeat across four years with normal staff turnover in the middle, and you arrive at the pause.
Where the Cost Actually Lands
- Change lead time. Every estimate is higher than the last, and the estimate is honest — it is reconciliation work, not padding.
- Regression testing. Each customisation is a surface that must be re-verified whenever anything near it moves, and surfaces interact. Testing effort tends to outgrow the system itself.
- Upgrade friction. Modifications sitting in the platform’s update path turn routine updates into negotiations.
- Concentrated knowledge. Undocumented logic lives in very few heads, and those heads are mobile.
- Unusable capability. New platform features arrive and cannot be adopted, so the organization pays for capability its own architecture will not let it take.
- Option value. The expensive one, and the only one with no paper trail.
That last item deserves its own sentence. A system that cannot absorb a new pricing model has removed a strategic option, and the discussion about that option ends long before it reaches anyone senior. Nobody records a decision that was never proposed.
The Point Where It Stops Being Reversible
Early on, debt is merely expensive. Changes cost more than they should, which is unpleasant and manageable.
Past a certain accumulation, something else happens. Some changes stop being expensive and become infeasible — not because the technology cannot do it, but because nobody can predict what the change would break, so it is not attempted. The tell is when the answer to “can we do this?” shifts from a number to a hesitation. By then the business has started designing around its own system, usually without noticing, because the options that disappeared were never formally on the table.
Why the Quick Fix Keeps Winning
The quick fix is not chosen out of ignorance. It wins because the incentives are clean, and it is worth being honest about that.
- It is cheap now and expensive later, usually on someone else’s watch. Ordinary discounting, applied to engineering.
- Prevention rarely produces a visible output. The reward for averting a problem is that nothing happens, which is difficult to report.
- The person best placed to object is the person under deadline. Often they are right to take the shortcut.
None of these is incompetence, which is why exhortation alone tends not to change the outcome and lightweight process usually does. The failure is rarely the shortcut itself. It is the shortcut nobody wrote down.
There is a second cause worth understanding, upstream of all of this: the pull toward rebuilding what the previous system did, simply because it is familiar. We have written about that separately in Why Comfort Zones Create Technical Debt in Dynamics 365 Projects.
Not All Debt Is a Mistake
- Deliberate, documented debt is a legitimate tool. A known shortcut with an owner and a review date is a financing decision, not a defect. Some engineering organizations run this explicitly, with a debt budget and scheduled repayment.
- Debt on a system you are genuinely retiring is usually not worth repaying. With one caveat: undocumented logic still has to be understood well enough to migrate, and retirement dates slip.
- Over-engineering is also a cost. Building for flexibility a process will never need is its own form of waste.
The distinction that matters is not clean versus messy. It is recorded versus forgotten. Debt you chose, wrote down and scheduled behaves like financing. Debt nobody remembers taking behaves like a lien on decisions you have not made yet.
The Discipline That Prevents It
- Fit to standard first, and make customisation earn its place. The test is not whether the platform can be made to do something. It is whether the business outcome actually requires it. Checking whether a standard module already covers the requirement is the cheapest step in the whole process, and the most frequently skipped.
- Build as extensions, because on current Dynamics 365 that is the supported model. Modifying the base application is no longer the available shortcut it was in the on-premises era — Finance and Operations moved to an extension-only model, and Business Central retired code customisation in favour of AL extensions. Extensions reduce upgrade breakage substantially, though they do not make it impossible: base-application changes and ISV dependencies can still require rework, so build with that in mind rather than assuming immunity.
- Give every exception an owner, a reason and a review date. An exception with a name attached gets revisited. An anonymous one becomes permanent.
- Route integration through one managed layer. Bilateral connections multiply quickly — a fully connected estate grows roughly with the square of the number of systems — and each connection is a private dependency on whoever built it.
- Roll changes in small, controlled increments. Modular releases with real testing between them keep the blast radius of any single exception small enough to unwind.
- Fund maintenance as a line item. Systems given no maintenance budget do not stop needing maintenance — they fund it silently out of the capacity you assumed was going to new work.
None of this is exotic. It is unpopular, because every item spends something visible today to prevent something invisible later.
DAX Software Solutions: Building Systems That Stay Changeable
Go-live is the wrong milestone to optimise for. It rewards whatever gets the system standing fastest, and the consequences land after the engagement has ended.
The more honest measure is what the tenth change costs compared with the first. That is the number DAX builds for, as a Microsoft Dynamics 365 implementation and support partner with more than twenty years in ERP and CRM — including a good deal of work rescuing implementations that were built for speed and became difficult to change. Our guide to rescuing an underperforming ERP system sets out how that work runs in practice.
Where DAX helps:
- Diagnosing why a system has become slow to change, through stakeholder interviews, performance analysis and gap analysis rather than assumption
- Reviewing existing customisations to identify what has become obsolete, redundant or a performance drain, then decommissioning or refactoring it
- Checking whether standard Microsoft Dynamics 365 capability already covers a requirement before anything gets rebuilt
- Reshaping processes before over-customising the system, so the platform is not bent to fit a legacy habit
- Rolling changes as controlled, modular increments that preserve stability
- Ongoing performance tuning and support through our Application Managed Services model, so debt gets caught rather than inherited
If the answer to “can we change this?” has become a hesitation rather than a number, that is diagnosable — and considerably cheaper to address before the next upgrade than during it. Get in touch with DAX Software Solutions to start that conversation.