Technical debt assessment: rank debt by what it costs the business

OutsourcingVN is operated by Netbase JSC, which sells assessment and modernization work, so we have an interest in what you decide. The method below works whoever performs it. It is written for CTOs, engineering leads, product owners and the finance owner who has to weigh remediation against new features.

What this guide covers

• What counts as technical debt, and what does not?
• How do you turn debt into a business decision?
• Which debt should be fixed first?
• How do you run the assessment?
• A worked scenario: a store two major versions behind
• What has Netbase delivered that bears on debt?
• Which questions should you ask a supplier?
• What failure modes should you watch for?
• Common questions
• How this guide is sourced
• Bring your change history and support dates

What counts as technical debt, and what does not?

Debt is any part of a system that makes the next change slower, riskier or more expensive than it would be in a cleaner design. Ward Cunningham's metaphor, as Martin Fowler describes it, separates the principal (the work needed to remove the cruft) from the interest (the extra effort every future change pays while it stays). That split is what makes debt measurable.

Four kinds turn up in almost every assessment: code debt (duplication, tangled modules, missing tests), platform debt (an unsupported runtime, framework or extension), architecture debt (coupling through a shared database, no seams between capabilities) and operational debt (manual releases, no monitoring, backups nobody has restored). A missing feature is not debt, and neither is an old library that is supported, stable and rarely touched.

Fowler's quadrant adds a useful question: was the debt deliberate or inadvertent, prudent or reckless? Deliberate, prudent debt taken to hit a launch date usually has a known repayment path. Inadvertent debt tends to hide in the modules changed most often, which is why it costs the most.

How do you turn debt into a business decision?

Engineers describe debt in code terms; budget holders need it in effort, risk and delay. Translate each item into three numbers the business already understands.

• Interest in effort. How many extra person-days does this item add to a typical change, multiplied by how often that area changes in a quarter?
• Exposure. What happens if it fails: a security incident, a failed release, an outage in a revenue path, a platform that stops receiving patches?
• Principal. A range for removing or containing it, with the unknowns listed, never a single confident figure.

Interest multiplied by change frequency is the number that ranks items. A module nobody touches can be ugly and cost nothing; a small, heavily edited module with no tests can quietly consume a sprint every quarter.

Which debt should be fixed first?

The last row matters. An assessment that recommends fixing everything has not ranked anything.

A worked scenario: a store two major versions behind

A retailer runs an online store on a commerce platform release that no longer receives security patches. Twelve third-party extensions are installed; four were customised by a previous agency. The team says every checkout change takes twice as long as planned. The scenario is illustrative and describes no client.

The ranking puts checkout tests first, because they make the migration safe to verify, and the admin theme last. The migration becomes a decision with a date instead of an item that sits on the backlog for another year.

What has Netbase delivered that bears on debt?

Two records on this site deal directly with platform and security debt on commerce systems.

• A platform migration with extension rework. For Netztech, Netbase delivered a Magento 1 to Magento 2 Commerce migration in 35 working days, including migrating 11 extensions with installation, configuration, customization and data transfer. The record publishes scope and duration only; no metric is claimed.
• Recovery of a compromised store. For an existing client store, Netbase scoped a three-phase recovery of a compromised Magento site: investigation and cause analysis, cleaning and system recovery, then file restore, recoding and hardening with security patches applied, typically 6 to 13 days in total depending on the damage. Recovery is never guaranteed, and the range is typical, not a commitment.

Netbase's registered upper bound for reuse is that reusing Netbase productized modules can cut development time by up to 60%. It applies to module reuse only; it is not a typical saving and says nothing about the debt in your system. Security practices on this work include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.

Which questions should you ask a supplier?

What failure modes should you watch for?

How this guide is sourced

Statements about Netbase map to approved claims backed by attested company facts listed under Sources, in their registered wording. The principal and interest framing and the deliberate-or-inadvertent quadrant come from Martin Fowler's published articles, dated below. The retail scenario is illustrative. The Netztech migration and the compromised-store recovery are the only delivery records cited here; Netbase publishes no measured debt reduction, velocity change or cost outcome for any client, and nothing on this page should be read as one. Our methodology explains how claims are reviewed.

Bring your change history and support dates

A first review goes furthest with a list of the areas that slow your team down, your platform and extension versions, and a view of recent incidents. Submit a project with them, or ask for a bounded technical audit sprint when you want the ranked register before any build. When the register points to structural change, legacy application modernization is the delivery route, and the other guides cover adjacent decisions. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Related services and solutions