Technology Debt, Part 2 – Diagnosing the Problem and Funding Transformation

Tony:
Hello, I’m Tony Mangino from TC2, and this is Staying Connected—where we talk about what really matters to enterprise buyers navigating today’s technology and sourcing decisions.

In our last episode, we defined technology debt as the accumulated cost and risk associated with legacy hardware, software, and wide area networks, and we talked about how that debt drives up run-rate costs, constrains innovation, and erodes competitive advantage.

Today, in Part 2, we’re going to look at how technology debt accumulates, why it’s hard to escape once it builds up, and what practical steps you can take to diagnose and quantify it so you can start building a roadmap to retire that debt and fund transformation.

I’m joined again by my colleague, Brent Knight. Brent, welcome back.

Brent:
Thanks, Tony. Glad to be here again.

Tony:
Let’s start with how we get into this position. None of this technology appears overnight. When you look across large enterprise environments, how do organizations end up with this level of technology debt?

Brent:
It’s almost never one big bad decision. It’s usually the cumulative impact of a lot of reasonable short-term decisions.

During cost-cutting cycles, refresh projects get deferred. That happens a couple of times, and suddenly you’re several versions behind on hardware or software. Mergers and acquisitions bring in additional systems and networks. Instead of rationalizing quickly, you run both environments in parallel for years.

Then you have tactical fixes: solving immediate problems for a line of business or region without stepping back to look at the overall architecture. In the moment, those decisions seem sensible, but over time they layer complexity onto complexity.

And in the network space especially, the incumbency advantage and general resistance to change (and risk) makes it easy to extend the status quo rather than rethink it. All of that adds up to a significant level of technology debt over time.

Tony:
So it’s a series of short-term optimizations that, aggregated over years, create a long-term structural problem.

Are there organizational dynamics that make it easier for technology debt to accumulate?

Brent:
Yes. One factor is how budgets and incentives are set up. Teams responsible for keeping the lights on are measured on stability and near-term cost, not on taking on transformative change that carries some risk.

Risk aversion, as I alluded to earlier, is another. In industries where uptime is critical, people remember the last big outage, and that memory can make organizations reluctant to touch core systems and networks.

And many enterprises simply don’t have a clear, multi-year architecture and sourcing roadmap that is tied to business objectives. Without that, it’s easy to default to incremental decisions that keep things running but don’t reduce the underlying debt.

Tony:
Even when leadership agrees they have too much technology debt, we see organizations struggle to act. What makes it so hard to unwind?

Brent:
There are a few big obstacles.

One is the sunk-cost mindset, you know, “sweat the assets”. If you’ve invested heavily in a particular platform or network, it’s hard to admit that moving away from it might be the right decision even while it’s still technically functioning.

Another is contractual. Long-term software and network contracts, with onerous terms and little flexibility, can make change look expensive or risky, even when the long-term economics favor modernization.

There’s also operational risk. Leaders worry – correctly – about disrupting critical systems and 24×7 operations. If transformation isn’t well-planned, it can create business disruption.

And finally, there’s capacity. Internal teams are already busy running the existing environment. Asking them to design and execute a major transformation program on top of that, without additional help, may not be realistic.

The common thread is that it’s hard to make good decisions in the abstract. You need a clear, quantified view of the problem – and a holistic, strategic solution.

Tony:
Let’s talk about building that view. If you’re a CIO, network leader, or sourcing executive listening today and you recognize your organization in this discussion, where should you start? What does a first-pass diagnosis look like?

Brent:
You can start by building a “bottoms-up” baseline across four areas: hardware, software, network, and financials.

For hardware, you inventory devices by type, age, and support status – servers, storage, network gear, and security appliances. Then look at basic metrics: failure rates, incident volumes, and maintenance costs. That highlights equipment that’s out of support, soon to be out of support, or disproportionately expensive to maintain.

For software, you list major applications and platforms, including versions, support status, and how heavily customized they are. You flag systems that are end-of-support or approaching end-of-life, and those that are difficult to integrate with modern cloud services.

For the WAN, you inventory circuits by site – technology, bandwidth, cost, and supplier. You overlay contract details: end dates, financial commitments, early termination penalties, renewal clauses, transition periods, etc. And you map the architecture: how much traffic is still being backhauled, where MPLS is truly required, and where Internet-based options could work.

On the financial side, you separate “keep-the-lights-on” run spend from project and transformation spend. That lets you see where legacy run costs are crowding out the budget you need for modernization.

Tony:
So the goal is to answer some basic questions with facts: what do we have, what does it cost, how risky is it, and where are the constraints on change.

Once you have that assessment, how do you turn it into an action plan?

Brent:
Organize it around three levers: retire, modernize, and replace.

Retire is about eliminating what you truly don’t need – systems, circuits, and hardware that no longer support critical functions. That might be redundant applications left over from acquisitions, circuits carrying no production traffic, tools that have been superseded or sites that have been shuttered.

Modernize means keeping the core function but updating the technology. That could involve upgrading to supported versions, moving workloads onto more modern platforms, or re-architecting pieces of an application that cause the most pain.

Replace is where you make a more fundamental change – moving to a different architecture or commercial model. In the network domain, a classic example is shifting from an MPLS-centric WAN to an Internet First model that uses SD-WAN and modern security architectures. That can significantly reduce run costs and improve agility.

You then prioritize based on risk, cost, and business value. Where are you most exposed? Where are you spending the most to get the least benefit? And where will change unlock the most agility or innovation?

Tony:
And that’s where some of the big roadmap efforts come in. In our work with clients, one of the most powerful levers for retiring technology debt is in the wide area network – for example, using an Internet First transformation to re-architect the underlay, introducing SD-WAN and modern security, and aligning contract events with technical milestones so you can migrate off legacy MPLS in a controlled way.

We’re going to devote an upcoming episode specifically to that Internet First WAN roadmap – how to assess your current WAN, design the target state, and source and execute that transformation without blowing up the business.

Brent, before we close Part 2, any final thoughts for listeners who are just starting this journey?

Brent:
Two quick thoughts.

First, don’t treat technology debt as an abstract concept. Treat it like any other liability: measure it, manage it, and deliberately reduce it over time. The diagnostic work we’ve talked about is what turns “we know we have a problem” into “here’s the business case and roadmap.”

Second, remember that retiring technology debt is often how you fund the transformations leadership wants. When you reduce the run-rate cost and risk of the legacy estate, you free up budget and capacity for initiatives that move the needle.

Tony:
That’s a great way to put it.  Brent, thanks again for joining me.

Brent:
Thank you, Tony.

Tony:
To our listeners, if you would like to discuss technology debt in your environment, or if you’d like to discuss other technology strategy, sourcing and cost reduction needs with Brent, me, or any of our TC2 and LB3 colleagues, please give us a call or shoot us an email.
You can also stay current by subscribing to Staying Connected, by checking out our websites, and by following us on LinkedIn.