Technical Debt Assessment: A Practical Checklist

A structured framework for assessing technical debt, covering code, infrastructure, processes, and knowledge. Includes a scoring model for prioritisation.

Best for: CTOs, IT managers, development leads Practical guide for business decision-makers

Who this is for

Technical leaders who know their systems have accumulated technical debt, but need a structured way to assess, quantify, and prioritise what to address.

Question this answers

How bad is our technical debt really, and what should we fix first?

What you'll leave with

  • A four-dimension framework for assessing technical debt
  • Specific checklist items for code, infrastructure, process, and knowledge debt
  • A scoring model to prioritise what to address first
  • How to communicate technical debt to non-technical stakeholders

What is technical debt?

Technical debt is the accumulated cost of shortcuts, deferred maintenance, and outdated decisions in your technology systems. Like financial debt, it compounds. Small amounts are manageable, but unchecked accumulation eventually constrains everything you try to do.

It's not just about messy code. Technical debt includes:

  • Systems running on unsupported platforms
  • Integrations held together by spreadsheets and manual processes
  • No documentation for why things work the way they do
  • Deployment processes that require a specific person's involvement
  • Security patches that never got applied because "it's too risky to change"

Every business with software has technical debt. The question isn't whether you have it; it's how much, where, and what to do about it.

Why assess it?

Most businesses know they have technical debt. What they lack is a structured view of how much, where it sits, and what to prioritise. Without this, technical debt gets addressed reactively, fixing things only when they break, which is the most expensive approach.

A structured assessment gives you:

  • Visibility: everyone agrees on what the debt is and where it lives
  • Prioritisation: fix what matters most, not what's most annoying
  • A business case: translate technical debt into business risk and cost so non-technical stakeholders understand why it matters
  • A plan: systematic reduction instead of reactive firefighting

The assessment framework

We assess technical debt across four dimensions. Each dimension has specific checklist items rated on risk (likelihood of causing a problem) and impact (severity when it does).

1. Code and architecture debt

This is what most people think of as technical debt, code quality, architecture decisions, and design patterns.

Code your developers are afraid to touch

  • Codebase has areas that developers avoid changing because they're fragile or poorly understood
  • Multiple versions of the same logic exist in different places (copy-paste code)
  • The application architecture doesn't support current requirements without workarounds
  • Third-party libraries or frameworks are significantly out of date (2+ major versions behind)
  • No automated tests exist for critical business logic
  • The application is a monolith that should have been decomposed years ago
  • Custom code exists where a standard library or service would work
  • Database structure has grown organically with no clear schema governance

2. Infrastructure debt

The platforms, servers, and environments your systems run on.

Servers and backups you cannot count on

  • Systems run on unsupported or end-of-life operating systems or runtimes
  • No disaster recovery or backup plan has been tested in the last 12 months
  • Deployments require manual steps or specific individuals
  • Infrastructure is not documented (server configs, network diagrams, access controls)
  • No monitoring or alerting exists for critical systems
  • Security patches are significantly behind (3+ months on critical systems)
  • Scaling requires manual intervention (provisioning servers, increasing resources)
  • Development, staging, and production environments are significantly different

3. Process and tooling debt

The tools, workflows, and practices that your team uses to build, test, and deploy software.

Releases that depend on manual steps

  • No CI/CD pipeline, deployments are manual
  • Source control is absent, outdated, or inconsistently used
  • No code review process for changes to production systems
  • Testing is entirely manual with no automated test suite
  • Incident response is ad-hoc, no documented process for outages
  • Project management and issue tracking is done in email or spreadsheets
  • No consistent development environment setup (every developer has different tools/versions)

4. Knowledge debt

What people know and what's documented. Often overlooked, but one of the most dangerous types of debt.

Know-how that lives in one person's head

  • Critical systems depend on one person's knowledge (bus factor = 1)
  • No documentation exists for system architecture, APIs, or deployment processes
  • Decisions about why things were built a certain way are undocumented
  • Onboarding a new developer takes weeks because there's nothing to read
  • The original development team or vendor is no longer available
  • Business rules are encoded in code with no external documentation
  • Admin credentials or API keys are held by individuals, not managed centrally

Scoring and prioritising

For each checked item, assign a score:

Low impact High impact
Low risk 1, Accept it 2, Plan to address
High risk 2, Plan to address 3, Address now

Risk = how likely is this to cause a problem in the next 12 months?

Impact = if it does cause a problem, how severe is the business impact?

Sum your scores across all dimensions. This gives you a total debt burden and, more importantly, a prioritised list of what to address first.

How do you explain it to the people who hold the budget?

"We need to restructure the order module" means nothing to a finance manager. Put it in business terms instead.

  • "Simple changes now take weeks. That will get worse every month we leave it."
  • "The software has known security holes that the maker no longer fixes."
  • "Our developers spend a large part of every week working around the same problems."
  • "We cannot connect the new payment provider until the framework is updated."

Put your own numbers against each one where you can. A rough estimate from your own time records is more convincing than "the code is hard to work with".

Keeping it under control

Some debt is normal. A business with none would never ship anything quickly. The aim is debt you know about, are paying down at a steady rate, and that is not blocking the work that matters.

  • Set aside a steady share of every month for paying it down, folded into normal work rather than saved for one big clean-up.
  • List it where everyone can see it, next to new feature requests. Debt that lives only in a developer's head never gets done.
  • Check it every quarter. Is it better or worse than last time?

Common mistakes

  • Trying to fix everything, some technical debt is acceptable. A stable system with outdated code comments doesn't need a rewrite. Focus on debt that creates risk or blocks capability.
  • Treating debt reduction as a project, it's not. It's ongoing hygiene. Allocate 15–20% of development capacity to debt reduction as a standing commitment.
  • Not involving the team, developers know where the bodies are buried. Run the assessment collaboratively with the people who work in the codebase daily.
  • Ignoring knowledge debt, code debt is visible. Knowledge debt is invisible until someone leaves. Document critical systems proactively, not reactively.
  • Conflating age with debt, old systems aren't automatically debt-ridden. A 10-year-old system that's well-maintained, documented, and secure has less debt than a 2-year-old system built in a rush with no tests.

Questions people ask

Is some technical debt acceptable?

Yes. Taking a shortcut on purpose to meet a deadline is a fair decision. The key words are "on purpose" and "written down". Trouble starts when debt builds up quietly.

Should we do one big clean-up or chip away at it?

Chip away, almost always. Big clean-up projects are hard to justify and are often cancelled halfway when priorities shift. Leaving each part a little better every time you touch it is steadier and less disruptive.

When is it time to replace the system instead?

When keeping it running costs more than building or buying a replacement, or every change is slow and risky. Our legacy system migration guide covers how to move without breaking what works.

Next steps

Run through the checklists above with your development team. Score each item, sort by priority, and pick the top 3–5 items to address in the next quarter.

If you'd like an independent assessment, book a technical audit with our team. We'll review your systems, quantify the debt, and give you a prioritised remediation plan, including honest advice about what to fix, what to live with, and what to replace.

Key takeaways

  • Technical debt isn't just bad code. It includes infrastructure, processes, tooling, and knowledge gaps.
  • Not all technical debt needs to be fixed. Some is acceptable. The goal is conscious, prioritised management
  • The highest-priority debt is high-risk AND high-impact: security vulnerabilities in critical systems, not outdated comments in stable code.
  • Use the assessment to build a business case. Translate technical debt into business risk and cost
  • Schedule technical debt reduction as ongoing work, not a one-off project. 15–20% of sprint capacity is a common allocation
Technical DebtSoftware ModernisationCode QualityAssessment

Meet the person

Written by the person who does the work

This guide comes from real projects. If it raises a question about your own system, you can ask the founder directly.

HELLO PEOPLE designs, builds and looks after AI, software, app and data solutions for Australian businesses, with senior expertise on every project and a scope agreed before work starts. For an older system, that means learning what it really does first, so nothing your business relies on is lost.

Since 2007, HELLO PEOPLE has delivered more than 100 projects from Perth for small and medium businesses across Australia: custom software and apps, system integrations, data migrations, reporting and dashboards, and AI that works inside the systems a business already runs.

I lead every engagement myself. I trained in accounting before moving into IT, hold accounting and IT professional qualifications and an MBA, and bring more than 20 years of experience across sales, service delivery, inventory and compliance. I am also a PhD candidate in AI at Curtin University, researching retrieval-augmented generation (RAG), so the technology is always judged by what it does for the business.

  • An old-fashioned service

    Small and boutique. The person who scopes the work is the person who does it, and the same person is there when the old system is switched off.

  • Quick responses

    No ticket queue and no account manager in between. You hear back within one business day, usually sooner.

  • A long-term partner

    The upgrade is the start, not the end. When you need the next system, integration or report, you call the same person, who already knows your business.

Ask the author

Still have a question?

Ask it here and it comes straight to the founder. No sales call, no obligation, and a real answer even if the answer is that you do not need us.

Kasun Wijayamanna, Founder Kasun Wijayamanna
Founder, replies within one business day

Get Started

Want help choosing the right next step?

Tell us what you are comparing, replacing, or trying to improve. We will come back with a practical recommendation and realistic scope.

Australian owned and operated

Built here. Your data stays here.

  • No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
  • Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
  • Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.