Technical Debt Is Not Old Code. It Is Unmanaged Decisions.
The age of a solution matters less than whether its rationale, ownership, and consequences are still understood.
This article is part of the Modernizing The Enterprise Platform series, which uses Salesforce as the evidence base for a broader discussion about enterprise architecture, AI, data, integration, identity, security, governance, DevOps, and operating models in mature enterprise platforms.
Technical debt is one of those phrases that gets used so often it can start to lose precision. In many enterprise conversations, it becomes a polite way to say old code, messy configuration, or something the current team would rather not defend. Sometimes that is fair. There is plenty of old code that should be retired, and plenty of configuration that made sense only because a delivery team was under pressure and needed to keep moving.
But age alone is a poor definition of technical debt. A customization can be old and still be completely appropriate. A recent solution can create immediate debt if it duplicates existing capability, ignores architectural boundaries, broadens permissions unnecessarily, or solves a local problem in a way that makes future change harder. The most damaging technical debt is often not obsolete code. It is a collection of decisions whose rationale, ownership, and consequences have been lost.
That distinction matters in mature Salesforce environments because the platform records decisions in a thousand small ways. A custom object reflects a process decision. A permission set reflects a trust decision. A flow reflects an operating assumption. An integration reflects a boundary between systems. A validation rule reflects a business control. A report folder reflects an information need. None of these things are only technical artifacts. They are decisions translated into platform behaviour.
Debt grows when exceptions become patterns without deliberate review. A team needs a temporary workaround, so a permission exception is granted. A business unit cannot adopt the standard process, so a separate flow is built. A downstream system cannot consume the preferred event, so a special integration path is created. Each decision may be defensible in isolation. The debt appears when the organization stops revisiting the decision and begins treating the exception as normal architecture.
I have seen this fear show up most clearly when teams want to remove something. Everyone agrees that the platform is too complex, but nobody wants to be the person who deletes the field, retires the flow, narrows the permission set, or changes the integration contract. The concern is not always that the component is valuable. Often the concern is that nobody knows why it exists, who depends on it, or what business consequence will appear after it is removed. Unknown reasoning creates operational fear.
What I find more interesting is that this makes technical debt a decision-management problem before it is a cleanup problem. Refactoring code may be necessary. Simplifying automation may be necessary. Replacing a package may be necessary. But if the organization does not improve how decisions are made, recorded, reviewed, and retired, the cleanup work will be temporary. New debt will accumulate under newer names.
This is why architecture decision records are useful when they are treated as practical memory rather than paperwork. Their value is not that they produce a perfect archive of every discussion. Their value is that they preserve enough context for a future team to understand what was decided, what alternatives were considered, what constraints mattered, what trade-offs were accepted, and what conditions should cause the decision to be revisited.
Salesforce teams often underestimate this because so much of the platform is declarative. It can feel less formal than code, and therefore less deserving of architectural record. That instinct is dangerous. A declarative choice can create just as much future constraint as an Apex class. A flow can become a business-critical automation path. A permission model can define what work is possible. A validation rule can enforce a regulatory control. A page layout can shape user behaviour. The fact that a change was made through configuration does not make it architecturally small.
AI increases the importance of this discipline. An AI agent that recommends, classifies, summarizes, or takes action will depend on decisions already embedded in systems. If those decisions are poorly understood, the agent may surface inconsistent information, act with excessive permissions, or follow process assumptions nobody currently owns. The issue is not that AI creates all of these problems. The issue is that AI makes unmanaged decisions more visible and, in some cases, more consequential.
A healthier way to evaluate technical debt is to look at business friction, operational risk, and cost of change. Does this component make it harder to deliver legitimate business change? Does it increase security or compliance risk? Does it force teams into manual workarounds? Does it duplicate another capability? Does it create a dependency nobody owns? Does it make incidents harder to diagnose? Does it preserve a decision whose original constraint no longer exists?
That kind of evaluation is more useful than asking whether something is old. It also prevents modernization from becoming cosmetic. A team can replace old code with new automation and still create debt if the new automation ignores ownership, boundaries, testing, rollback, and future maintainability. Modern tools do not protect an organization from unmanaged decisions.
To be clear, I am not arguing that code quality, platform limits, and implementation patterns do not matter. They matter a great deal. Poor technical execution can create real debt. What I am arguing is that the deeper enterprise problem is often the loss of decision context. When teams cannot explain why the system behaves the way it does, they become hesitant to change it and vulnerable to repeating the same mistakes.
Modernization should therefore include more than cleanup. It should include a better way to make and preserve architectural decisions. Not every decision needs a ceremony, and not every trade-off needs a long document. But meaningful decisions need enough memory that future teams are not forced to reverse-engineer intent from production behaviour.
Technical debt is not simply the residue of old work. It is what happens when decisions outlive the reasoning that made them safe.
Continue The Series
- 1. Salesforce Is Still Part Of The Conversation. It Is No Longer The Boundary.
- 2. The Hardest Salesforce Work Starts After Go-Live
- 3. Enterprise Platforms Do Not Become Complex Because They Are Old
- 4. Technical Debt Is Not Old Code. It Is Unmanaged Decisions.
- 5. Enterprise Platforms Fail When Responsibility Exceeds Authority
- 6. DevOps Is An Operating Control, Not A Deployment Tool
- 7. Your Most Important Enterprise Users May Not Be Human
- 8. AI Agents Do Not Fix Weak Enterprise Architecture. They Expose It.
- 9. Enterprise AI Should Not Be Deterministic Everywhere
- 10. An Architecture Recommendation Is Incomplete Until It Explains What Was Rejected
- 11. Modernization Is The Art Of Changing The System Without Stopping The Business