Salesforce Technical Debt: How to Find It and Pay It Down

Short answer: Salesforce technical debt is the accumulated cost of every past shortcut still sitting in your org, in clicks as much as in code. You find it with a full metadata inventory joined to usage data. You pay it down in the order your roadmap demands, not top to bottom, because debt that blocks nothing on the roadmap can wait, sometimes indefinitely.

What is Salesforce technical debt?

Technical debt is the extra work a future change will cost because of a decision taken earlier. On Salesforce it accumulates faster than on most stacks, for two structural reasons: a change is one admin and five clicks away, and nothing in the platform expires when people stop using it.

It arrives in four shapes:

• Automation debt. Workflow Rules, Process Builder processes and Flows doing overlapping work, in a firing order nobody can draw on a whiteboard.
• Configuration debt. Fields nobody has filled in two years, layouts for roles that no longer exist, profiles carrying permissions that belong in permission sets.
• Code debt. More than one trigger per object, tests written to reach a coverage number rather than to assert behaviour, hardcoded IDs.
• Integration debt. Callers pinned to API versions the platform no longer serves, and middleware whose owner has left the company.

Only the fourth kind breaks loudly. The other three quietly tax every project you run.

Where is it hiding right now?

Two dated items are worth checking this week, because the platform moved and most orgs did not.

• Workflow Rules and Process Builder are past end of support. Salesforce set that date at 31 December 2025. Anything still on them keeps running, but bugs will not be fixed and you cannot build new ones. The Migrate to Flow tool exists for exactly this.
• Legacy API versions are gone. Platform API versions 21.0 through 30.0 across SOAP, REST and Bulk were deprecated in Summer '22 and retired with Summer '25. Callers now receive 410 GONE on REST, 500 UNSUPPORTED_API_VERSION on SOAP and 400 InvalidVersion on Bulk. If an old nightly job went quiet, check this first.

How do you inventory debt without stopping delivery?

1. Run Salesforce Optimizer and export it. Free, in Setup, and it hands you a starting list rather than an opinion.
2. Retrieve the org metadata into source control. Even if you never deploy from it, you now have something to grep, diff and count.
3. Join the inventory to usage. Field history, report and dashboard subscriptions, page views, Apex logs. A field with no reads and no writes in twelve months is a candidate; the same field on an object carrying 400 others is a priority.
4. Map dependencies before you delete anything. The where-is-this-used question is the entire difference between a cleanup and an outage.
5. Name an owner per area. Debt with no owner is never paid.

For a mid-sized org this is a two-week exercise that runs alongside a normal sprint. What it produces is a register, not a project plan.

How should you rank what you found?

This is where most debt programmes go wrong. Ranking by severity orders the list by how bad things look; ranking by effort orders it by how easy they are. Neither is a list your business will fund twice.

Rank against the roadmap instead. For every item in the register, ask one question: which committed roadmap item does this make slower, riskier or impossible? That single question sorts the register into three tiers.

• Blocking. The roadmap item cannot ship until the debt is paid. Do the work inside that project, funded by that project, with its business case.
• Taxing. The roadmap item ships anyway, but costs more or carries risk it should not. Do it in the sprint before, tightly scoped.
• Dormant. Nothing on the roadmap touches it. Log it, monitor it, do not fund it.

Two categories override the ranking: anything with a security or compliance consequence, and anything failing silently in production. Those are fixed regardless of what the roadmap says, because their cost is not paid in delivery time.

Why does wholesale cleanup fail?

Three reasons, and we have watched all three.

1. No visible outcome. An org-wide cleanup produces no feature and no number a sponsor can point at, so it loses its budget the first time priorities are re-cut.
2. Attribution damage. Deleting metadata nobody was watching causes an incident, the incident gets attributed to the cleanup, and the next one never gets approved.
3. It never converges. An org that shipped all year has fresh debt before the sweep finishes. Pay-down attached to roadmap items ends when the item ships.

The goal is not a clean org. It is an org where the next twelve months of roadmap can be delivered at a predictable cost.

What cadence actually works?

• Every sprint. A fixed slice of capacity, commonly 10 to 20%, spent on taxing debt in the areas the next stories touch.
• Every Salesforce release. Three times a year, re-run Optimizer, re-read the retirement notices and re-check the API versions your integrations request.
• Every year. Refresh the inventory and re-rank against the new roadmap. Dormant debt sometimes becomes blocking overnight.

One preventive control outperforms all three: deploy from source control, so org state is reproducible and every change arrives with an author, a reason and a test. Debt you can see in a diff rarely becomes debt you discover in an incident.

We run this inventory at the start of engagements rather than after the first surprise, which is part of how we have taken 16+ organisations live on Salesforce. Want a second opinion on your org before committing next year's roadmap? Start here.

FAQ

How do I know if my org has too much technical debt?

Measure it in delivery, not in counts. If routine changes need regression testing across unrelated areas, or if nobody can predict what a change will break, the debt is already expensive.

Should we delete unused fields?

Only after a dependency check, and only when something on the roadmap benefits. Unused fields are usually dormant debt, and dormant debt is the cheapest thing to leave alone.

Is Salesforce Optimizer enough?

It is the right first move, not the last. Optimizer flags platform-level issues but cannot tell you which stand between you and next quarter's roadmap.

Do we have to migrate off Workflow Rules and Process Builder now?

They still run, but passed end of support on 31 December 2025, so defects stay unfixed. Migrate the automations your roadmap touches first, not all at once.