Technical debt in business systems: how to spot it and pay it down

The conversation usually starts somewhere else. Someone asks for a new field on the order form, or a report split by region, or a connection between two systems that already hold the same customer. The answer comes back as six weeks and a caveat, and nobody in the room can explain why something so small costs so much. That gap between how simple a change sounds and what it actually takes is the clearest signal a business gets that it has accumulated technical debt.

What is technical debt in a business system?

Technical debt is the extra effort every future change costs because of the way existing systems were built, extended and maintained. Ward Cunningham introduced the metaphor in 1992, and as Martin Fowler puts it, the extra effort it takes to add new features is the interest paid on the debt.

In a business context it is broader than source code. Debt also accumulates in:

• Integrations, where systems are joined by fragile scripts, overnight file drops or manual exports.
• Data, where the same customer exists three times with different spellings and no agreed source of truth.
• Process, where a spreadsheet or an inbox rule performs a step that no system owns.
• Knowledge, where how something works lives in one person rather than in documentation.
• Currency, where software runs on versions the vendor no longer supports.

The important reframe for a leadership team is that technical debt is not a tidiness problem. It is a change-cost problem, and it becomes visible exactly when the business wants to move.

What does technical debt look like if you do not read code?

You do not need a code audit to find it. Five symptoms are reliable, and operations and finance leaders usually recognize all of them.

Small changes take a long time. A field, a rule, a report. When trivial requests are quoted in weeks, the system is charging interest on every change.

Integrations break, and breaking is routine. The nightly file did not arrive, so someone rekeys orders. A format changed, so the feed failed silently and finance found the gap a week later. The pattern matters more than any single incident. Widespread disconnection is normal: the 2025 MuleSoft Connectivity Benchmark Report found the average enterprise manages 897 applications with only 29% of them integrated.

Spreadsheets hold the process together. A shared workbook calculates the pricing the ERP cannot, tracks the approvals nobody built a screen for, or reconciles two systems each morning. Every such spreadsheet is a business process with no owner, no access control and no backup plan.

One person understands the system. Requests queue behind them, changes wait for their return, and nobody wants to think about their resignation. This concentration is the fastest-moving risk on the list, because it can change overnight.

Software versions are past support. When a vendor ends support, security patches stop. The US Government Accountability Office examined 11 critical federal legacy systems ranging from 23 to 60 years old and found four with unsupported hardware or software and seven with known cybersecurity vulnerabilities that could not be remediated without modernization.

The aggregate cost is substantial. CISQ estimated that accumulated software technical debt in the US, meaning the cost of reworking suboptimal software, had grown to approximately $1.52 trillion, within a total cost of poor software quality of $2.41 trillion.

Illustrative example: Consider a wholesale distributor with about 200 staff. Its order entry system was built in 2013, extended twice, and now carries customer-specific pricing rules that exist nowhere else. A nightly export moves orders into the accounting system, and when it fails, an operations coordinator rekeys them, which happens most months. Two people know how the pricing rules work and one is retiring in a year. Nothing is broken enough to be an emergency, so nothing is scheduled. Then the company wins a national account requiring an EDI connection and a same-day order confirmation, and the answer is that the change is possible but will take two quarters. The debt did not cause a failure. It removed the option to say yes.

How do you assess and prioritize technical debt?

The mistake is trying to fix everything, which produces a long program with no visible benefit and gets cancelled. Fowler's guidance is directly useful here: crufty but stable areas of code can be left alone, because you only pay the interest when you have to work in them.

So prioritize against the change you actually intend to make in the next 12 to 18 months. A practical assessment takes a couple of weeks:

1. List the systems and connections that support your main operational processes, including the spreadsheets.
2. For each one, record four facts: how often it changes, how long a typical change takes, how many people can safely change it, and whether it runs on supported versions.
3. Add the incidents. Failed jobs, manual reworks, data corrections. Frequency is more informative than severity.
4. Overlay your plans. Which of these does the next year of commercial commitments depend on?
5. Score impact against effort and decide deliberately.

The last row matters as much as the first. Deciding not to act, on the record and for stated reasons, is a legitimate and often correct outcome.

Should you pay it down incrementally or rewrite?

Full rewrites are attractive because they promise a clean end state, and they fail more often than the people proposing them expect. The reason is not engineering fashion. It is that a long-running system encodes years of decisions nobody wrote down, and the rewrite only discovers them by getting them wrong.

Incremental replacement is the safer default. Fowler's strangler fig pattern describes it well: build new components alongside the old system and move behavior across piece by piece, so investment and returns happen gradually and visibly, each step is small enough to reverse, and the business keeps operating throughout.

A rewrite becomes defensible in narrower cases: the platform is genuinely unsupportable, the vendor has gone, nobody can operate it safely, or the process it supports has changed so completely that the old model no longer fits. Even then, replace in stages and run old and new in parallel with one clearly designated source of truth.

Either way, treat it as a delivery project with a business owner, agreed measures and a defined first slice. Our guide to what drives the cost of custom software covers how to budget that work, and planning a legacy application migration to the cloud covers the infrastructure side.

Why do AI initiatives expose technical debt so quickly?

Because an AI system is only as good as the data and the systems it can reach, and reaching them is exactly where debt lives. In the same MuleSoft report, 95% of organizations said they face challenges integrating AI into existing processes and 80% cited data integration as their most significant obstacle.

Three patterns recur. An assistant meant to answer questions from company knowledge finds the knowledge scattered across drives with no ownership. An automation meant to update a record discovers the system has no usable API, or that the license does not include API access. A workflow meant to remove manual effort turns out to depend on a spreadsheet nobody maintains.

The effect extends to how AI tools are used in engineering. Google's 2025 DORA report found 90% of respondents using AI at work and about 30% reporting little or no trust in AI-generated code, and concluded that AI amplifies what a team already has rather than fixing it. In the Stack Overflow 2025 Developer Survey, 45% said debugging AI-generated code is more time-consuming. Adding AI-assisted output to a system nobody fully understands increases the volume of code faster than the ability to review it.

The constructive reading is that an AI project is a good forcing function. It surfaces the integration and data problems that were already costing you, with a business case attached. A readiness assessment usually finds them before they become a surprise, as what happens in an AI readiness assessment describes.

How do you stop new debt accumulating?

Prevention is mostly governance rather than technology, and it costs very little once it is habit:

1. Name an owner for every system, including spreadsheets that run a process and apps built on no-code platforms.
2. Record deliberate shortcuts. One line: what was skipped, why, and what would trigger revisiting it. Debt you decided to take is manageable; debt you drifted into is not.
3. Fund maintenance as a standing item, not as an exception you have to argue for each year.
4. Require documentation and a second pair of hands for anything operationally important, so no system has exactly one person who understands it.
5. Track supported versions and diary end-of-support dates with your renewals.
6. Insist on ownership at handover. Code in a repository you control, cloud accounts in your name, credentials you can rotate.
7. Prefer integration to duplication. Every new copy of the same data becomes a reconciliation job later, as build, buy or integrate discusses.
8. Review quarterly, briefly. What slowed down, what broke twice, what is now past support.

How Kastling approaches technical debt

Kastling is an AI solutions and implementation partner, and most of what we do starts inside systems a business already runs rather than on a blank page. We prefer to connect existing systems rather than replace them, and we look at the work before the technology.

Where a current process is unclear or spread across teams, a separately scoped, paid audit reviews the workflows, systems and data pipelines and identifies where time and effort are going, producing a current-state assessment, prioritized opportunities and a recommended approach. That assessment usually names debt explicitly, including the parts we would advise leaving alone.

When work follows, Custom Solutions covers internal tools, dashboards, portals and web or mobile applications, with or without AI, and we agree before development starts how success will be measured and who owns the data, the code and the accounts. We build and test against real business scenarios with the people who use the system, hand over documentation and training, and offer ongoing maintenance under a separate agreement so that the software has a funded owner after launch rather than becoming next year's debt.