.png)
Every mid-market company carries technical debt. The ones that manage it well know what they are carrying, what it costs, and when they intend to pay it down.
Any chief financial officer (CFO) can tell you, to the dollar, what the company owes. Term debt, the line of credit, lease commitments, deferred compensation: each has a balance, a rate, and a maturity date, and each gets reviewed every quarter.
Ask the same leadership team what its technology will cost to maintain, secure, modernize, or eventually replace, and the precision disappears. Few can answer, because no one has ever asked them to put a number on it.
That unrecorded burden has a name: technical debt. It is not a liability in the accounting sense, but it is a real obligation of the business. Carrying some technical debt is normal and often sensible. The trouble is that its carrying costs accumulate where finance rarely looks, and it tends to come due at the worst possible moment: a system fails during quarter-end, an incident halts operations, or a buyer’s diligence team finds it first.
What Is Technical Debt?
Technical debt is the future cost, constraint, and risk an organization accepts when it chooses a faster or cheaper technology path today over a more durable one. Like financial debt, it buys something real: a go-live date met, a budget held, an acquisition folded in within a quarter instead of a year. And like financial debt, it carries interest. That interest is paid in manual effort, slower projects, higher risk, and systems that limit what the business can do next.
Very little of it started as a bad decision. A customization that made sense in 2014, a spreadsheet built to bridge two systems after an acquisition, a server kept running because replacing it was never urgent. Each was reasonable at the time. Left in place for years and layered on top of one another, they compound into something no one chose, and no one owns.
Across the mid-market organizations we work with in GBQ’s Business Technology Solutions (BTS) practice, four forms of technical debt show up more consistently than any others.
1. The ERP Nobody Wants To Touch
The pattern is familiar. The company implemented its Enterprise Resource Planning (ERP) system ten or fifteen years ago and customized it heavily to match how the business ran at the time. Upgrades were deferred because every upgrade broke something custom. The version in production is now at or near the end of vendor support, and the logic behind the customizations lives in the head of one long-tenured employee or a consultant who moved on years ago.
The carrying cost shows up every time the business wants to change. A new pricing model, a new location, a new product line, or an integration with a modern sales or planning tool becomes a custom project with a custom price tag. Over time, the business starts adapting its processes to the system instead of the other way around. Meanwhile, the data inside the ERP, often among the company’s most valuable operational assets, sits in structures that are difficult to report on, govern, integrate, or use reliably in automation and artificial intelligence (AI) initiatives.
The larger bill arrives later. The vendor ends support, a key person leaves, or growth outruns the platform, and the company is forced into a replacement on someone else’s timeline. That is the most expensive way to buy a core system: a compressed schedule, little negotiating leverage, and a migration made harder by every year of accumulated customization and data.
2. The Close That Runs On Spreadsheets
In many mid-market companies, the financial close depends on a set of spreadsheets that stitch together systems that were never integrated. The general ledger lives in one place, billing in another, payroll and inventory somewhere else. Each acquisition added another entity and another export. Month-end means pulling reports, reconciling by hand, and rebuilding the management package in a workbook that one analyst understands completely and everyone else is afraid to edit.
This debt is expensive precisely because it is hard to see. None of it appears in the technology budget. It shows up instead as added finance headcount, a close that takes two weeks when a more mature process might take one, and leadership making decisions on information that is already stale when it arrives. Every manual handoff is a place where an error can enter unnoticed, and version control comes down to trusting the file name.
The exposure sharpens as the company grows. Spreadsheet-based reporting that worked for one entity strains at four. It also draws scrutiny in a transaction. When a buyer’s quality-of-earnings team finds that reported results depend on manual reconciliations and one person’s knowledge, the conversation shifts from growth to reliability, and that shift rarely helps the seller.
3. Infrastructure Past Its Support Date
The third form lives underneath everything else: servers, operating systems, network equipment, and line-of-business applications running past the date their vendors stopped issuing security patches. Remote access configured in a hurry in 2020 and never revisited. Security controls added one at a time in response to individual incidents or insurance questionnaires rather than designed as a program.
This debt is paid in risk, and it compounds quietly until it doesn’t. An unsupported system receives no new security patches, so every newly disclosed vulnerability stays open unless the company isolates the system, puts compensating controls around it, or replaces it. Recovery gets harder too. Restoring an environment built on aging, poorly documented infrastructure takes longer, and every day of downtime is a day of lost revenue.
The insurance market has noticed. Cyber insurers routinely evaluate controls such as multi-factor authentication, endpoint protection, backups, privileged-access management, and patch management during underwriting, and end-of-life systems invite closer scrutiny that can affect eligibility, terms, sublimits, exclusions, or premium.
This is where deferral looks cheapest on paper and can cost the most in practice. Replacing infrastructure that still runs is easy to push to next year. But a single serious incident, once downtime, recovery, legal exposure, and customer impact are counted, can exceed years of the investment that was deferred. As I wrote in an earlier column on cybersecurity, the gap in most organizations is execution, not knowledge.
4. The CRM Behind A Wall Of Admins
The fourth pattern is newer; it is especially common in professional services firms, and it usually starts with a sound purchase. The firm selects a top-tier Customer Relationship Management (CRM) platform, then balks at the cost of licensing everyone who should be using it. Instead of putting the tool in the hands of its rainmakers, the firm licenses a small team of administrators and routes the work through them. Partners and senior sellers email or call an admin to log a meeting, update a contact, pull a pipeline report, or launch a campaign.
The license savings are real and easy to see on the invoice. The cost of the workaround is spread across payroll and lost opportunity, where no one adds it up. The honest comparison is the fully loaded cost of the administrative layer, plus the time and opportunity it costs sellers and partners, against the cost of licensing and enabling the people the platform was bought for. Run that math and many firms discover they are paying twice: once for a platform they are not fully using, and again for the labor required to work around it.
The damage compounds in the data. Every activity reaches the system secondhand, late, and filtered through someone who was not in the room, so the pipeline leadership reviews is only as current as the last round of requests. The automations the platform was purchased to deliver, such as lead routing, follow-up sequences, and forecasting, run partially or not at all because the people whose activity should feed them never touch the system. Client relationships stay in individual inboxes and memories, which becomes a very expensive problem the day a rainmaker leaves. And the longer the arrangement runs, the more process forms around the admin layer, and the harder it is to unwind.
The Net Effect
These four examples look like separate problems owned by separate people: the ERP belongs to operations, the spreadsheets to finance, the servers to information technology (IT), and the CRM to sales. Their economic effect is the same. Each moves cost out of a visible technology project and into labor, delay, rework, control weakness, lost opportunity, and risk, where it is rarely measured as the cost of technology.
That matters because the consequences land in different places. Some appear as operating expense. Some consume capital. Some drag on productivity or slow revenue-generating activity. Some surface only when an incident occurs, an auditor identifies a control weakness, or a buyer performs diligence. The accounting treatment differs, but the management problem does not: the organization is carrying an unmeasured obligation that competes directly with future growth.
The most useful single indicator is how a company splits its technology spend between running what exists and building new capability. When nearly all of the budget and the team’s time goes to keeping current systems alive, little is left for the initiatives leadership wants to fund, including the AI and automation work boards are now asking about. We covered what separates AI that scales from AI that stalls in our AI readiness framework for mid-market companies. Technical debt is often the first thing standing in the way.
Owners and private equity sponsors should watch the transaction effect closely. Sophisticated buyers look for aging platforms, unsupported infrastructure, manual workarounds, key-person dependencies, and systems likely to require significant investment or disrupt operations after close. When the seller has already identified the issue, quantified it, and built a credible remediation plan, it becomes a diligence item. When the buyer finds it first, it becomes leverage.
Manage It Like Any Other Liability
Not all technical debt should be paid off. Some of it is inexpensive to carry, well understood, and low risk, and retiring it would be a poor use of capital. The discipline is the one a CFO already applies to any material commitment: identify it, quantify the carrying cost and downside risk, weigh both against the investment required to address it, and sequence remediation against the company’s strategy and capital plan.
In practice, that means a technical-debt register. For each item, it should capture the affected system or process, the business owner, the current workaround and what it costs to operate, the estimated cost to remediate or replace, any security or compliance exposure, key-person dependencies, operational impact, and a target disposition. Items tied to security exposure, unsupported platforms, unreliable financial reporting, customer commitments, or constraints on growth belong near the front of the line.
The work starts with a few questions leadership can put to its technology team this quarter:
- What share of our technology spend goes to maintaining existing systems, and what share builds new capability?
- Which of our critical systems are at or past the end of vendor support?
- Which platforms are we paying for but not fully using, and what are we spending to work around them?
- Where does a critical process depend on one person’s knowledge?
- Which manual workarounds exist only because our systems do not connect?
- If we went to market in eighteen months, what would a buyer’s diligence team find?
If the answers come back vague, that is the finding. This is the work we do every day in GBQ’s BTS practice: putting a number on what a company’s technology environment will cost to maintain, secure, modernize, and eventually replace, then building a paydown plan that fits the capital plan instead of competing with it. Every company’s technical debt comes due eventually. Better to set that timeline yourself than to have a system failure or a buyer set it for you.
About GBQ Business Technology Solutions
GBQ's Business Technology Solutions practice empowers the growth of our clients across six disciplines: risk management, cybersecurity, IT governance, AI and automation, data and analytics, and business systems.
If this article raised questions that you cannot yet answer about your own cybersecurity strategy, the first place to start is with a conversation. GBQ’s cybersecurity advisory services allow us to assess where your organization stands today, prioritize use cases worth your investment, and help build the governance that lets you prove what AI is returning.
To continue the conversation, schedule time with Doug Davidson, director of GBQ’s Business Technology Solutions practice. Or, contact him directly at ddavidson@gbq.com.
Net Effect is a biweekly column written by Doug Davidson, director of the firm's Business Technology Solutions, published in the firm's Bottomline newsletter. Email ddavidson@gbq.com to have your technology questions addressed in a future column.
