ChatGPT
Claude
PerplexitySalesforce technical debt is the accumulated cost of configuration and code that works today and constrains change tomorrow. It raises the price of every subsequent project, and most organizations carry it without a number attached to it.
This page does three things in sequence. It defines technical debt using the measurements that exist rather than metaphors. It shows the native Salesforce instruments that expose debt at no cost. It sets out how remediation gets sequenced, and where AI both helps and hurts.
McKinsey defines technical debt as off-balance-sheet technology work
The most useful definition comes from finance rather than engineering.
McKinsey’s research on measuring and taming technical debt describes it as the off-balance-sheet accumulation of all the technology work a company needs to do in the future, and compares it to dark matter: you know it exists, you can infer its impact, and you cannot see or measure it directly.
That framing matters for Salesforce specifically. A Salesforce org does not present a bill for its debt. It presents a slower change request, a longer estimate, a failed deployment, or an admin who declines to touch a flow nobody documented. The cost is real and it arrives distributed across every future project rather than as a line item.
Salesforce technical debt takes a particular shape because the platform is configurable by people who are not developers. Fields, flows, validation rules, permission sets and page layouts all accumulate without a code review, which means debt in Salesforce grows through clicks as readily as through code.
Technical debt consumes over 20 percent of the technology budget at 30 percent of companies
The numbers on this subject come from a McKinsey survey of 50 CIOs at financial services and technology companies with revenue above $1 billion, alongside analysis of 220 companies across five geographies and seven sectors.
| Finding | Figure |
|---|---|
| CIOs who believe more than 20% of their new-product technology budget is diverted to tech debt | 30% |
| CIO estimate of tech debt as a share of total technology estate value, before depreciation | 20% to 40% |
| Firms that completed modernization programs and still failed to reduce technical debt | Almost half |
| Revenue growth advantage of the 80th percentile Tech Debt Score against the bottom 20th | 20% higher |
| Increased likelihood of incomplete or canceled modernization in the bottom 20th percentile | 40% |
| Share of IT change spend the bottom 10th percentile puts into applications they would retire | Almost half |
Two of those findings deserve isolating.
Almost half of completed modernization programs failed to reduce technical debt. Spending money on modernization does not, on its own, pay debt down. McKinsey attributes this to organizations modernizing applications that were not major debt contributors.
Age does not predict debt. McKinsey reports little correlation between the age of an enterprise and its level of technical debt, and cites a bank founded more than fifty years ago that reached the top 20 percent of Tech Debt Scores. A five-year-old Salesforce org can carry more debt than a fifteen-year-old one.
One insurer in the same research found technical debt amounted to 15 to 60 percent of every dollar spent on IT, a figure absent from the business cases that had been failing to win approval.
Salesforce groups technical debt into security gaps, conflicting truth and outdated automation
Most articles on this topic borrow a generic software-engineering taxonomy. Salesforce publishes its own, and it is more useful because it is platform-specific.
The Trailhead technical debt module is an intermediate-level, administrator-audience badge running roughly one hour forty-five minutes, structured in four units:
| Unit | What it targets |
|---|---|
| Manage Technical Debt | Prioritizing debt by risk |
| Close Security Gaps | Permissions, profiles and access that accumulated without review |
| Maintain One Version of the Truth | Duplicate and conflicting sources of the same data |
| Update Automations | Legacy automation that still runs and is no longer supported |
Read those four together and Salesforce is making a claim about where debt actually concentrates in its platform: access, data truth, and automation. Not code volume. Not field counts.
The module sits on the Build Your Architect Career trail, and Salesforce lists AI Ethics and Trust among the skills it develops. That inclusion on a technical debt module is a signal in itself: Salesforce connects org hygiene to whether AI can be trusted to act on the org.
A messy org differs from technical debt in what cleanup can repair
The distinction decides whether your remediation plan should be a tidy-up or a redesign, and teams frequently pick the wrong one.
Clutter is unused fields, duplicated reports, inconsistent naming and stale dashboards. Clutter slows people down. Disciplined cleanup removes it.
Technical debt is brittle architecture. Three automations firing on the same object in an order nobody controls. A data model where one business concept lives in four objects. A permission structure where nobody can say who sees what. Cleanup does not fix any of that, because the problem is the shape rather than the volume.
The test is simple. Ask whether deleting things would solve it. If yes, it is clutter. If deleting things would break something and nobody is confident which thing, that is debt.
Both are worth addressing. Only one of them justifies a project.
Salesforce exposes technical debt through six native instruments at no cost
Vendor tools for this problem are good and most organizations buy one eventually. Before that, the platform already reports on itself, and these six are free.
Org Check. Salesforce retired the Optimizer app with the Winter ’26 release, and the Salesforce Labs project Org Check replaced it. It reports unused and inefficient components, maps technical debt across metadata, and scores the org against best practice. It installs from AppExchange or runs as an sf CLI plugin against any org.
Security Health Check. Scores the org’s security settings against a Salesforce baseline and lists every setting below it. This is the Close Security Gaps unit made measurable.
The Usage tab in the Automation Lightning App. Shows flow dependencies and the impact of a change before you make it. The instrument that prevents remediation from creating new incidents.
Field usage and object limits in Setup. Custom field counts per object against edition limits give a hard ceiling, and objects approaching that limit are usually the ones carrying the most unexamined history.
Apex test results and code coverage. Coverage above the 75 percent deployment threshold with assertions that verify nothing is a specific and common form of code debt. Reading the tests matters more than reading the percentage.
Debug logs and the Apex exception email. Recurring runtime errors nobody has claimed are debt that has already started charging interest.
None of those requires budget approval. All of them produce numbers you can put in front of a finance leader, which is the step that most remediation proposals skip.
Deployment time inflation measures Salesforce debt better than component counts
Component counts describe size. They do not describe cost. An org with 900 fields and clean architecture is healthier than an org with 300 fields and six competing automations.
The measurement that tracks the actual burden is how long a standard change takes now against how long the same change took a year ago.
Pick three representative changes and time them:
- Add a custom field to a core object and expose it to one profile. Baseline: under an hour.
- Modify a validation rule on an object with existing automation. Baseline: under half a day including verification.
- Deploy a small change from sandbox to production. Baseline: same day.
If those take multiples of the baseline, the difference is the interest payment. That number converts directly into money, and it is the number that gets remediation funded, because it answers the question a CFO asks: what is this costing us now.
Two supporting measures are worth tracking alongside it. Failed deployment rate indicates hidden dependency debt. Time from ticket raised to root cause identified indicates documentation debt, because a team that understands its own org diagnoses quickly.
AI code generation adds technical debt faster than most teams measure it
This deserves a direct answer from a firm that builds with agents, because the concern is legitimate and currently one of the most active discussions in the Salesforce practitioner community.
Generative tools produce Salesforce configuration and Apex at a speed no human matches. Output volume is no longer the constraint. Three failure modes follow from that.
Generated code inherits no architectural context. A model asked for a trigger produces a working trigger. It does not know that two other automations already fire on that object, and it does not know your naming convention or governance standard unless the surrounding system supplies them.
Review capacity becomes the bottleneck. Debt accumulates when the rate of change exceeds the rate of considered review. Faster generation without faster review is a debt accelerator, whatever the quality of any individual output.
Plausible output passes inspection. Generated Apex reads well. Reading well and behaving correctly against ten thousand records under governor limits are different properties, and the first one is easier to mistake for the second.
The determining factor is not whether AI writes the code. It is whether the system generating the code holds context about the org and whether a senior engineer owns the judgment. Generation without org context and without review produces debt at scale. Generation grounded in the org’s actual metadata, with an experienced engineer accountable for what ships, does the opposite.
GetGenerative.ai agents review, remediate and run Salesforce orgs
Our managed services model is built around this problem, and three agents map to three stages.
Metadata Agent reviews. It builds a complete as-is view of the org from metadata, configuration, code, architecture patterns and Salesforce MCP connections. It identifies technical debt, detects architecture drift, surfaces risk and complexity, and prioritizes remediation actions.
Build Agent remediates. It converts remediation priorities into implementation workbooks, configuration changes, code updates and deployment-ready fixes, then deploys to sandbox.
Support Agent runs. It handles bugs, enhancements and business-as-usual requests with AI-led triage, impact analysis, fix generation, testing and documentation.
The reason this addresses the AI debt problem rather than adding to it sits in the context layer. The platform connects four sources before recommending anything: business process, metadata, code base and Salesforce MCP. An agent that can see the automations already firing on an object, the dependencies attached to a field, and the business process behind both, produces different output than one working from a prompt alone. Salesforce FDEs then own architecture alignment, quality and governance.
The full loop runs review, prioritize, remediate, resolve, validate, improve. Because analysis, documentation, fix preparation and testing absorb most of the manual effort in traditional support, automating them is what takes managed services cost down by up to 80 percent while experts stay in control.
If you want the measurement before the commitment, the complimentary Org Review produces a health check, a technical debt assessment, a remediation roadmap and five open support tickets fixed in one day, with 30 days of platform access, at no cost. Details are on AI-powered managed services, and the wider health-check framework sits in the org assessment that finds it.
Remediation sequences by risk rather than by ease
The instinct is to start with the easiest items. The evidence argues against it: McKinsey found almost half of completed modernization programs failed to reduce technical debt, largely because organizations modernized what was convenient rather than what was expensive.
A defensible sequence runs in four passes.
Pass one: security and access. Overlapping permission sets, profiles nobody owns, sharing rules with no stated purpose. This is first because it carries compliance exposure as well as change cost, and because Salesforce puts it first.
Pass two: unsupported automation. Anything still running on retired tooling. It works, nobody supports it, and every release is a risk carried without a support path.
Pass three: duplicate truth. Two fields holding the same business concept, two objects modeling one process, two reports producing different answers to the same question. This is the pass that restores trust in reporting.
Pass four: clutter. Unused fields, stale dashboards, orphaned components. Worth doing, and worth doing last, because it produces the least risk reduction per hour spent.
Two disciplines make the sequence hold. Delete rather than deactivate, because a deactivated component still counts against limits and still confuses the next person. And check dependencies before every change, using the Usage tab, because remediation that creates an incident stops the program.
McKinsey’s operating-model recommendation applies here too: price technical debt into all IT services, so that the cost of the debt any new work creates is visible at the point the work is approved rather than three years later.
Salesforce technical debt, condensed
| Definition | Off-balance-sheet accumulation of technology work a company must do in future |
|---|---|
| Salesforce concentration points | Security gaps, conflicting sources of truth, outdated automation |
| Share of technology budget diverted | Over 20% at 30% of surveyed companies, per McKinsey |
| Debt as share of technology estate value | 20% to 40%, per CIO estimates |
| Modernization programs that failed to reduce debt | Almost half |
| Revenue growth advantage of the top TDS percentile | 20% higher than the bottom 20th percentile |
| Correlation with company age | Little to none |
| Best free measurement tools | Org Check, Security Health Check, Automation Usage tab, field and object limits, Apex coverage, debug logs |
| Best business measure | Deployment time inflation against a prior baseline |
| Remediation order | Security, unsupported automation, duplicate truth, clutter |
| Biggest new risk | Generation speed exceeding review capacity |
Questions teams ask about Salesforce technical debt
What is Salesforce technical debt?
Salesforce technical debt is the accumulated cost of configuration and code that functions now and constrains change later. McKinsey defines technical debt generally as the off-balance-sheet accumulation of technology work a company needs to do in the future. In Salesforce it accumulates through clicks as well as code, because configuration changes rarely pass through review.
How much does technical debt cost?
McKinsey’s survey of CIOs at companies with revenue above $1 billion found 30% believe more than 20% of their new-product technology budget is diverted to resolving technical debt, and that CIOs estimate debt at 20% to 40% of the value of their entire technology estate before depreciation. One insurer found debt equaled 15% to 60% of every dollar spent on IT.
How do I measure technical debt in a Salesforce org?
Start with free instruments: Org Check for unused components and limit usage, Security Health Check for access gaps, the Usage tab in the Automation Lightning App for flow dependencies, field counts against object limits, Apex coverage and assertion quality, and recurring debug log errors. Then measure deployment time inflation, which converts the finding into a cost.
What are the main types of Salesforce technical debt?
Salesforce’s own Trailhead module organizes it into security gaps, multiple conflicting versions of the truth, and outdated automations, with prioritization by risk running across all three. Configuration debt, code debt, architectural debt, integration debt and documentation debt are useful sub-categories underneath that structure.
Is a messy Salesforce org the same as technical debt?
No. Clutter is volume and cleanup fixes it. Technical debt is architecture, and cleanup does not fix it. The practical test is whether deleting things would solve the problem. If deleting would break something and nobody is confident which thing, that is debt.
Does AI increase or reduce Salesforce technical debt?
Both, depending on the surrounding system. Generation without knowledge of the org’s existing automation, naming standards and dependencies produces debt at speed, and review capacity becomes the bottleneck. Generation grounded in the org’s metadata, business process and code base, with an experienced engineer accountable for what deploys, reduces debt instead.
Where should remediation start?
With security and access, then unsupported automation, then duplicate sources of truth, then clutter. McKinsey found almost half of completed modernization programs failed to reduce technical debt, largely because organizations modernized what was convenient rather than what was costly.
Does technical debt affect business performance?
McKinsey’s analysis of 220 companies found companies in the 80th percentile of its Tech Debt Score had revenue growth 20% higher than those in the bottom 20th percentile, and that bottom-percentile companies were 40% more likely to have incomplete or canceled IT modernization programs.
