Technical Debt: When Is It a Business Problem — and When Is a Rewrite a Mistake?

Sooner or later, someone in an established software company says:

“We need to rewrite the system.”

Sometimes they are right.

Sometimes the codebase has become a genuine constraint on the business: releases are risky, incidents repeat, security changes are difficult, infrastructure costs are unreasonable, or one old subsystem prevents the company from shipping what customers need.

But sometimes “technical debt” means something much less urgent:

“I would design this differently if I started today.”

Those are not the same thing.

A company should not spend months rebuilding software simply because newer technology exists or engineers dislike old code.

The useful question is:

What is this technical debt costing the business now, and what will it prevent us from doing next?

That turns technical debt from an engineering complaint into an investment decision.

Technical debt is not simply old code

Code can be old and still be valuable, stable and cheap to operate.

Code can also be six months old and already expensive to change.

Age is a weak diagnostic.

Technical debt is better understood as a design, implementation, operational or organizational shortcut whose consequences make future work harder, riskier or more expensive.

Examples include:

• A module that every feature must modify.
• No automated coverage around critical financial logic.
• A deployment process only one engineer understands.
• Duplicate business rules implemented differently across services.
• A database structure that makes a required product change dangerous.
• Dependencies that can no longer receive security updates.
• Manual operational work that repeatedly causes incidents.
• Architecture that cannot support an upcoming scale or compliance requirement.

The business problem is not that the code looks ugly.

The problem is the consequence.

Translate debt into a business consequence

When an engineering team asks for technical-debt work, ask them to complete this sentence:

Because of this debt, we currently lose or risk ______.

A useful answer might be:

• A normal release requires two days of regression work.
• Billing incidents recur because three systems calculate the same rule differently.
• We cannot safely upgrade a dependency with known security exposure.
• Every enterprise customer integration requires modifying the same fragile module.
• Only one engineer can deploy the platform.
• Infrastructure cost grows faster than usage because of an architectural constraint.
• A product initiative on the roadmap cannot be implemented safely with the current data model.

Now leadership can compare remediation with other investments.

“Bad architecture” is difficult to prioritize.

“Every customer integration costs two extra engineering weeks because of this coupling” is much easier to reason about.

Not all technical debt should be paid

Debt is an economic metaphor for a reason.

Some debt has low interest.

Imagine an internal admin screen built quickly three years ago. The code is not elegant, but it changes once a year, causes no incidents and has no security concern.

Rewriting it may produce almost no business value.

Now imagine another imperfect module sits in the checkout path and changes every week.

Its debt has much higher interest because every future change pays the penalty.

So prioritize debt partly by change frequency and business criticality.

Ugly code in a quiet corner can be less important than moderately messy code in the center of the product.

The four costs I look for

A useful technical-debt discussion usually connects to at least one of four cost categories.

1. Delivery cost

Does the debt make valuable changes slower or more expensive?

Look for:

• Repeated workarounds.
• Long regression cycles.
• Unexpected dependencies.
• Excessive review requirements.
• Features touching many unrelated areas.
• Engineers avoiding parts of the codebase.

2. Reliability and security risk

Does the debt increase the probability or impact of failure?

Examples:

• Unsupported dependencies.
• Missing observability.
• Fragile deployments.
• Repeated production incidents.
• Weak authorization boundaries.
• Critical logic without reliable tests.

3. Operating cost

Does the architecture create unnecessary recurring expense?

That can include cloud infrastructure, manual operations, support load, vendor cost or excessive engineering time.

4. Strategic constraint

Does the debt prevent something the company needs to do?

For example:

• Enter an enterprise market.
• Support a required compliance model.
• Launch multi-tenancy.
• Integrate a new channel.
• Separate a product line.
• Scale a workload.
• Change pricing or billing architecture.

Strategic constraints can justify work even before they create visible incidents.

Technical debt can also be organizational

Not every technical bottleneck lives in source code.

Consider a production system where:

• Nobody knows who owns a service.
• Documentation is missing.
• Only one person knows the deployment procedure.
• Architecture decisions exist only in old chat messages.
• No team owns dependency upgrades.

A rewrite does not automatically fix any of this.

You can create a beautiful new codebase and reproduce the same organizational debt around it.

Technical leadership has to address ownership, operating practices and knowledge distribution as well as code.

Why engineers naturally want rewrites

A rewrite is attractive because it offers a clean mental model.

The current system contains years of compromises, edge cases and historical decisions.

A new system appears simpler because it has not encountered reality yet.

That creates a dangerous comparison:

Old production system with all known complexity

versus

New design before all production complexity returns

The second will almost always look cleaner on a diagram.

But many of the strange rules in a legacy system exist because the business discovered something the original designers did not know.

Before deleting them, understand why they exist.

A rewrite does not start from zero

Even if you discard every line of old code, the business still has:

• Existing users.
• Existing data.
• Integrations.
• Permissions.
• Billing rules.
• Operational procedures.
• Historical edge cases.
• Reporting expectations.
• Support workflows.
• Contracts and commitments.

The rewrite must rediscover or migrate all of them.

That is why estimating a rewrite by comparing source-code size is misleading.

You are migrating a running business system, not reproducing a repository.

The hidden cost: two systems at once

During a rewrite, the old product usually cannot stop changing.

Customers still need fixes.

Sales still closes deals.

Security issues still appear.

The company now has to decide:

• Do we implement a new feature in the old system?
• Wait for the new system?
• Build it twice?
• Freeze part of the business?

This creates a period of dual-system cost.

The longer the rewrite lasts, the larger that cost can become.

When a rewrite is usually a weak argument

Be cautious when the main justification is:

• The framework is not fashionable anymore.
• A new language would be faster in theory.
• The team prefers another architecture style.
• The code is not as clean as we would write it today.
• Microservices would look more scalable.
• A competitor uses a newer stack.

None of these is automatically wrong.

But they need a demonstrated constraint or opportunity behind them.

Technology preference alone is a weak reason to put working business functionality at migration risk.

When a rewrite becomes more credible

A rewrite deserves serious consideration when incremental change cannot reasonably remove a material constraint.

Examples might include:

• A core platform boundary is fundamentally incompatible with the required product model.
• The technology can no longer be safely maintained and migration paths are impractical.
• The existing data or tenancy architecture makes a strategic requirement unsafe to implement incrementally.
• Reliability failures originate from a design that cannot be isolated or progressively replaced at acceptable cost.
• The organization must support a new operating model that the existing core cannot accommodate.

Even then, “rewrite everything” is only one migration strategy.

Refactor, replace or rewrite?

These decisions are often presented as two choices:

Keep the legacy system or rewrite everything.

There are more options.

Refactor in place

Improve the existing code while continuing to ship.

Useful when boundaries can be improved incrementally and behavior is mostly correct.

Isolate

Put a stable interface around a problematic subsystem so fewer parts of the product depend directly on it.

Useful when the subsystem is ugly but still functional.

Replace one capability

Move one domain — such as search, billing, notifications or reporting — behind a new implementation.

Useful when the debt is concentrated.

Strangler migration

Gradually route capabilities away from the old system into new components while the product continues operating.

Useful when a large-bang migration would be too risky.

Full rewrite

Rebuild the complete system and migrate users/data/workflows.

Sometimes necessary, but it carries the largest migration surface and should have a proportionate business case.

Fix the boundary before the implementation

A common mistake is rewriting a bad module without changing why it became bad.

Suppose ten parts of the product directly manipulate billing tables.

You rewrite billing beautifully, but allow the same ten parts to manipulate the new tables.

The coupling returns.

A more durable improvement might first create a clear billing boundary and move callers behind it.

Architecture debt often lives in relationships between components, not just inside their code.

Measure hotspots, not opinions

Instead of asking developers to name the worst code, combine their experience with evidence.

Look for areas with combinations of:

• High change frequency.
• High defect frequency.
• High incident impact.
• Long review or test cycles.
• Many dependencies.
• High cognitive load.
• Significant business importance.

A module engineers dislike but rarely touch may not be the highest-value target.

A module everyone changes and nobody trusts probably deserves attention.

Build a technical-debt register that a CEO can read

A useful debt item can be represented like this:

Problem: Checkout rules exist in three implementations.

Evidence: Similar production defects occurred repeatedly and every pricing change requires coordinated edits.

Business impact: Higher release risk and engineering effort for revenue-critical changes.

Proposed action: Move pricing rules behind one owned interface, then migrate callers incrementally.

Expected result: One source of truth for pricing behavior and smaller change surface.

Risk of waiting: More duplicated behavior as new pricing features are added.

Notice what is missing:

“Code quality: 4/10.”

A score without consequences rarely helps an executive choose where to invest.

Rank debt by exposure, not embarrassment

You can use a simple qualitative model:

Impact × Frequency × Change Demand × Risk Exposure

Then consider remediation cost and reversibility.

You do not need fake mathematical precision.

The purpose is to distinguish:

• High-impact debt in a frequently changing critical path.
• Risky debt that needs containment soon.
• Opportunistic debt to fix when nearby work happens.
• Cosmetic debt that can remain.

A mature engineering organization is comfortable deciding not to fix some debt.

The Boy Scout rule has economic limits

Improving code while touching it can be useful.

But “leave everything cleaner than you found it” can become uncontrolled scope if every feature turns into a refactoring project.

A better rule is:

Improve nearby debt when the improvement is bounded, lowers the risk of the current change, or clearly reduces repeated future cost.

Large structural changes should be visible decisions, not hidden inside unrelated tickets.

Technical debt and product deadlines

A common conflict sounds like:

Business: We need the feature this month.

Engineering: We need three months to fix the architecture first.

Both sides may be reacting to real constraints.

The useful discussion is not “features versus quality.”

Ask:

• What is the minimum remediation required to ship this feature safely?
• What debt will this feature make worse if we do nothing?
• Can we isolate the new capability?
• What risk are we accepting by postponing remediation?
• When will that accepted debt be revisited?

This creates explicit trade-offs instead of permanent conflict.

Sometimes the fastest path is to stop adding debt

You may not have budget for a major modernization project.

You can still change the trajectory.

For a problematic area:

1. Define ownership.
2. Stop introducing new direct dependencies.
3. Add tests around critical behavior.
4. Add observability where failures are hard to diagnose.
5. Create an interface around the area.
6. Migrate behavior gradually as product work touches it.

The system may become materially easier to change without a rewrite program.

Use incidents as architecture evidence

Repeated incidents are useful signals.

Do not only ask:

Who made the mistake?

Ask:

Why could this class of mistake repeatedly reach production?

Perhaps:

• Critical behavior has no automated protection.
• The deployment process is fragile.
• Ownership is unclear.
• A shared component has an excessive blast radius.
• The system allows invalid state.

Incident learning can reveal technical debt with direct business evidence.

Security debt deserves a different threshold

Not every debt item can wait for a visible incident.

Unsupported software, weak access boundaries, exposed secrets, missing security updates or dangerous privilege models can create risk before the company experiences a failure.

For security-sensitive debt, evaluate credible exposure and potential impact rather than waiting for historical frequency.

Infrastructure cost can expose architecture debt

Cloud cost is sometimes a pricing problem.

Sometimes it is an architecture problem.

For example, a workload may repeatedly process the same data, keep oversized resources running continuously, or scale an entire application because one component is resource-intensive.

Before rewriting, identify the actual cost driver.

A targeted architecture change may produce most of the benefit with much less migration risk.

“We cannot hire people who know this stack” needs evidence too

Talent availability can be a legitimate strategic concern.

But validate it.

Ask:

• Are candidates truly unavailable, or is the hiring process weak?
• Can engineers learn the stack?
• Is the unusual technology isolated or spread across the platform?
• Would migrating it reduce total operating risk enough to justify the cost?

Changing technology creates its own hiring and learning curve.

The rewrite test

Before approving a full rewrite, I would want clear answers to these questions:

1. Which measurable business constraint does the current system create?
2. Why can that constraint not be removed incrementally at acceptable cost and risk?
3. What behavior, data and integrations must be preserved?
4. How will old and new systems coexist during migration?
5. How will data migration be verified?
6. What is the rollback or containment strategy?
7. How will ongoing product development continue?
8. What milestone proves the new architecture is actually removing the constraint?

If the plan cannot answer these, the organization probably has a technology aspiration, not yet a migration strategy.

A better modernization sequence

For many systems, a safer sequence is:

Observe → Measure → Stabilize → Define boundaries → Isolate hotspots → Replace incrementally → Remove old paths

That sequence lets the company learn before committing the entire platform to one architectural bet.

It also produces value during the migration rather than only at the end.

How I approach a codebase audit

A useful codebase audit should not end with a long list of everything an engineer could improve.

It should answer:

• What is creating business or operational risk now?
• What is slowing important roadmap work?
• Which areas are safe enough to leave alone?
• Which problems need containment?
• Which problems justify refactoring or replacement?
• Which architectural decisions are difficult to reverse?
• What sequence gives the company the highest reduction in risk or delivery cost?

The output should be ordered by consequences, not by personal coding preferences.

The goal is not a clean codebase

No production codebase is permanently clean.

Businesses change.

Requirements change.

Teams change.

Technology changes.

The goal is a system that the company can change safely enough, quickly enough and economically enough for where the business is going.

Sometimes that requires serious modernization.

Sometimes it requires a rewrite.

And sometimes the most responsible technical decision is to leave an ugly but stable subsystem alone.

Is technical debt slowing your roadmap — or is the team proposing a rewrite without a clear business case?

I can review the architecture, delivery hotspots, reliability risks and modernization options, then separate debt that is costing the business from debt that can safely wait.

Discuss an AI & Codebase Audit or Engineering Architecture review with Fady Mondy.

The objective is not to rewrite more software. It is to spend engineering effort where it changes the economics or risk of the business.

---

Related: AI & Codebase Audits, Engineering Architecture, Engineering Leadership, Fractional CTO, Custom Software Development, and Why Is Your Software Project Late When the Engineering Team Is Busy?