Software Architecture Review and Technical Debt Assessment: Fix, Refactor or Rebuild?
How software architecture reviews and technical debt assessments work: scope, evidence, scalability, security, maintainability, priorities and when to rebuild.
What does an architecture review and debt assessment deliver?
A good review tells you, with evidence, which parts of your system put the business at risk or slow it down, and what to do about them in priority order. It covers scalability, security, reliability, maintainability, dependencies and team constraints, and usually recommends targeted fixes rather than a rebuild. Technical debt is assessed by business impact, not by how old or untidy code looks.
This guide is for CTOs, product owners and business leaders deciding whether their software needs refactoring, partial replacement or a rebuild. For online stores specifically, see ecommerce architecture audit and ecommerce technical debt; for older systems, legacy software modernisation.
Key takeaways
- Define the business questions first: growth, reliability, cost, security, speed of change.
- Gather evidence: code, infrastructure, incidents, metrics, delivery data and interviews.
- Assess debt by impact, not by age or style.
- Prioritise fixes that reduce risk and speed up valuable change.
- Rebuild only when evidence shows incremental change is worse.
- Record decisions so the next review starts from facts.
Scope and evidence
- Architecture: components, boundaries, data flows and integrations; a C4-style diagram helps (C4 model).
- Code: structure, test coverage of critical paths, duplication, complexity hotspots.
- Dependencies: framework and library versions, unsupported components, licences.
- Infrastructure: hosting, environments, deployment process, backups.
- Security: authentication, authorisation, secrets, known vulnerabilities.
- Operations: incidents, monitoring, on-call pain.
- Delivery: lead time for changes, failure rate, where changes get stuck.
- People: team size, skills, key-person risk.
What reviewers assess
| Dimension | Questions |
|---|---|
| Scalability | What breaks first at 2x, 5x, 10x load? Is the database the constraint? |
| Reliability | What fails, how often, and how fast is recovery? |
| Security | Where could data leak or be changed without authorisation? |
| Maintainability | How long do typical changes take, and why? |
| Dependencies | What is unsupported, outdated or risky? |
| Cost | What drives infrastructure and operating cost? |
| Team fit | Can the current team operate and change this architecture? |
Worth noting
The AWS Well-Architected Framework's pillars (operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability) are a useful checklist even for systems not on AWS (AWS).
Assessing technical debt
List debt items with evidence, then score each on impact (incidents, security risk, slowed changes, cost) and effort. Look for clusters: a single poor data model often causes many symptoms. Distinguish deliberate debt (a known shortcut) from accidental debt (unclear design), and code that is ugly but stable from code that is fragile and frequently changed. Change frequency combined with defect history is a strong signal of where debt hurts most.
Fix, refactor, replace or rebuild
| Option | When it fits |
|---|---|
| Leave alone | Stable, rarely changed, low risk |
| Targeted fixes | Specific hotspots, upgrades, missing tests |
| Refactor incrementally | Valuable system with structural problems; tests can be added |
| Replace a component | One part blocks progress; clear boundary exists |
| Rebuild | Evidence shows incremental change costs more and carries more risk |
Turning findings into a roadmap
Present findings with evidence and business impact, not just technical labels. Group recommendations into quick risk reductions, enabling work (tests, upgrades, observability) and structural changes. Reserve regular capacity for debt work alongside features. Record significant decisions as architecture decision records so future teams know why choices were made (Michael Nygard).
Hypothetical example
This example is hypothetical. A booking platform's leadership asks whether to rebuild after repeated outages. The review finds three causes: a reporting query running on the primary database at peak times, no automated tests around payments, and an unsupported framework version. Recommendations: move reporting to a replica, add payment tests before changes, and upgrade the framework in stages. A rebuild is not recommended. Outage causes are tracked monthly afterwards.
Common mistakes
- Deciding to rebuild before reviewing the evidence.
- Treating all old code as debt.
- Findings with no business impact or priority.
- No capacity reserved for debt work.
- Reviews by people who will profit from a rebuild, without an independent view.
Related guides
Finding single points of failure
A reliability-focused review looks for single points of failure: components, people or suppliers whose loss would stop an important service. Walk through each critical user journey, such as sign-in, checkout or payroll, and ask what happens if each dependency fails.
- Infrastructure: single instances, single availability zone, one database without a tested replica or restore.
- Data: backups in the same account or with the same credentials; restores never tested.
- Network and edge: DNS, certificates and CDN configuration; expiring certificates and domains without auto-renewal.
- Third parties: one payment provider, email service or API with no fallback or degraded mode.
- Jobs and queues: a single scheduler or worker that silently stops.
- People: one engineer who knows how to deploy or holds the only admin access.
- Access: shared or single administrator accounts, missing break-glass procedures.
- Monitoring: alerts that depend on the system they monitor.
Prioritising reliability findings
Rate each finding by the impact on users and the business and the likelihood of failure, then pick the cheapest effective fix: documentation and a second person with access, a tested restore, auto-renewal, a timeout and fallback, or redundancy where the impact justifies it. Not every single point of failure needs removing; some are acceptable if recovery is fast and rehearsed. Feed the results into business continuity planning and monitoring.
Conclusion
An architecture review and debt assessment should replace opinions with evidence: what is risky, what slows the business, what can wait. Most systems need targeted fixes and incremental refactoring, not a rebuild. Prioritise by impact, reserve capacity, and record decisions.
Wondering whether to rebuild?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web application architecture and mobile apps. If it would help to get an evidence-based view before deciding, we are happy to talk it through.
Common questions.
A structured assessment of how a system is built, covering its components, data flows, dependencies, infrastructure, security, scalability and maintainability, against the business's current and expected needs. It produces findings with evidence and a prioritised set of recommendations. It is usually a few weeks of investigation, not a redesign.