More than half of the custom objects built in Salesforce orgs are never used by the business. That finding comes from Elements.cloud, which analyzed a year of metadata from 100 production orgs in 2023 and also found that 43% of custom fields added to standard objects had never held a single value. Every one of those fields still appears in page layouts, reports, validation rules and the next consultant’s impact analysis. Nobody plans this. It builds up one reasonable request at a time, and by the time anyone notices, a small change to the Opportunity object takes a week of tracing. Untangling an org like that is mostly forensic work, which is part of why Crunch-IS is a leader in Salesforce development services, with engagements that begin from a metadata inventory rather than a backlog. The harder question is where customization stops paying for itself.
The org nobody designed
Salesforce Ben’s 2026 admin survey, answered by more than 1,100 professionals in 72 countries, named technical debt the biggest challenge of the job for the second year running. Nearly a third of respondents (31%) described their debt as high or very high, enough to slow delivery on a regular basis. Only 2% called their org clean and well maintained.
Age explains a lot of it. More than 60% of the orgs in that survey are over five years old, and a quarter have passed a decade. A ten-year-old org has outlived several admins and usually two implementation partners, each of whom left decisions that made sense at the time.
Where the debt actually sits
Technical debt in Salesforce rarely looks like bad code. Far more often it looks like one of these:
- Dead schema. Elements.cloud found only 23% of custom objects were still being updated 90 days after they were created. The rest is clutter that every deployment still has to carry.
- Retired automation still running. Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025. Orgs that still run them have automation nobody will patch, firing alongside newer record-triggered flows and Apex triggers on the same object, in an order few people on the team can predict.
- Triggers written for one record. Apex runs under governor limits of 100 SOQL queries and 150 DML statements per synchronous transaction, with 10,000 milliseconds of CPU time. A trigger that queries inside a loop passes every test with five records and fails on the first data load of a few hundred.
- Hardcoded IDs. Record type and user IDs pasted into code break the moment a sandbox is refreshed or a second org enters the picture.
- Packages nobody owns. Installed for a pilot, still holding fields and permissions, never removed.
The 75% test coverage Salesforce requires before Apex reaches production catches none of this. Coverage measures lines executed, not whether the code survives bulk data, and plenty of orgs clear it with tests that assert nothing.
What it costs outside the org
CISQ put accumulated software technical debt in the US at about $1.52 trillion in its 2022 report on the cost of poor software quality. Stripe’s Developer Coefficient study found developers spend 17.3 hours of a 41.1-hour week on maintenance work, 13.5 of those hours on technical debt. And in a McKinsey survey of 50 CIOs, respondents said 10 to 20 percent of the technology budget meant for new products gets diverted to resolving debt-related issues.
Inside a Salesforce org, that diversion shows up in sprint velocity. A request for one new field turns into a dependency hunt across flows, reports, integrations and Apex classes. Releases slow down. Admins start turning requests away, not because the ideas are bad, but because nobody can predict what a change will break.
Why it gets worse before it gets better
Forrester predicted that more than half of technology decision-makers would see their technical debt reach moderate or high severity in 2025, and that the share would reach 75% by 2026. Salesforce orgs sit on the same curve with an extra accelerant: AI. Agents and copilots read the schema to decide what to do. An org with three fields that all claim to hold “customer tier” gives a model three answers and no way to choose between them. Nearly 59% of the Salesforce Ben respondents already say the platform is getting harder to work with, and every layer built on an untidy org inherits that.
A cleanup order that holds up
- Inventory before deleting. Pull population rates and last-modified dates for every custom field and object. Anything empty after 12 months is a candidate for removal, not a verdict.
- One automation framework per object. Move the remaining Workflow Rules and Process Builders to Flow, then consolidate. Salesforce’s Migrate to Flow tool produces a separate flow for each rule, which recreates the sprawl in a newer format.
- Bulkify every trigger and route logic through handler classes, so each object has a single entry point.
- Replace hardcoded IDs with custom metadata types or dynamic lookups.
- Write tests that assert outcomes on batches of 200 records, not tests that exist to hit a percentage.
- Gate new customization. Every new field gets an owner, a reporting use and a condition under which it will be retired.
The sequence matters. Deleting fields before mapping dependencies breaks integrations nobody documented, and one broken nightly sync is usually enough to end a cleanup programme.
Configuration is never free
Salesforce has always sold the idea that you can change it without code, and that part is true. What clicks-not-code really does is defer the cost onto whoever touches the object next. A field that takes minutes to create can take days of dependency tracing to remove safely three years later. Teams that treat every customization as a liability with a named owner keep their orgs fast. Teams that treat it as free pay for it in every release, without ever seeing the invoice.