Salesforce Org Cleanup: How I Approach an Org with Years of Technical Debt

At some point in your Salesforce career, you’ll get that project. Not a clean implementation. Not a recently launched Sales Cloud org. I mean the one that has survived multiple admins, multiple consulting partners, a few reorganizations, and at least one sales leader who kept saying, “just add a field for now.” 

You open Account or Opportunity and the scrollbar just keeps going. There are hundreds of fields. Page layouts take forever to load. Nobody is completely sure what the automation is doing anymore. And everyone in the company has learned to work around Salesforce instead of relying on it. 

I’ve walked into orgs like this more than once. The first reaction many people have is that the company should simply start over in a brand-new org. In reality, that almost never happens. The integrations are too intertwined, reporting depends on historical data, and the business cannot tolerate a large migration project. So, the real challenge becomes figuring out how to fix the system while the business continues to run on it every day. 

After more than 5-7 years without governance, the same patterns appear almost everywhere. Standard objects like Account, Contact, Opportunity, and Case often have hundreds of custom fields. Page layouts are cluttered and slow. Workflow Rules, Process Builder, and Flows are all running simultaneously and sometimes perform overlapping actions. There is Apex code that no one wants to modify because nobody knows what depends on it. Reports exist that have not been opened in years, and documentation is either outdated or nonexistent. 

The consequences go far beyond inconvenience. Users lose trust in the system, performance degrades, and even simple configuration changes feel risky. New admins become hesitant to touch anything because one small modification could unexpectedly affect another department. At this point the org is not just messy — it becomes a business risk. 

The first mistake teams make is starting the cleanup immediately. Deleting fields or layouts right away sounds productive, but it usually causes problems very quickly. Someone inevitably relies on something you removed, and suddenly the cleanup effort loses support. 

Before touching the system, I always align with leadership and stakeholders. I explain that this is not a cosmetic project. The goal is to improve reporting accuracy, system performance, onboarding, and the company’s ability to safely make changes in the future. I typically agree on measurable outcomes such as reducing unused fields, improving page performance, simplifying automation, and making the org maintainable for future admins. Once stakeholders understand that this directly impacts operations and reporting reliability, they support the effort. Without that buy-in, cleanup projects rarely succeed. 

The next step is visibility. You cannot clean what you cannot see. Most organizations significantly underestimate the number of metadata inside their Salesforce org. Before making any changes, I take a complete inventory. I run config workbook, analyze field usage with Field Trip, export configuration data, and pull metadata using SFDX and dependency tools. I catalog fields, record types, layouts, automation, Apex code, reports, and dashboards. This step alone often changes stakeholder perception because they finally see the scale of the complexity. 

Field usage analysis is where the real story emerges. When you review field population over time, patterns become clear. Some fields have not been populated in over a year. Some exist in only a tiny percentage of records. Others are duplicates created by different admins trying to solve the same problem at different times. You also discover fields tied to processes that the company no longer even follows — old products, outdated reporting structures, or previous management initiatives preserved inside the data model. 

After understanding fields, I move to record types, page layouts, and automation. Many record types were created for short-term needs but never retired. Layouts were copied repeatedly and slowly accumulated unused fields. Important information is often buried while irrelevant fields remain visible. 

Automation is usually the most dangerous part of the system. It is common to find Workflow Rules still active, Process Builder duplicating Flow logic, Flows triggering Apex, and Apex triggering additional automation. Before removing anything, I map dependencies carefully to ensure business processes are not interrupted. 

Cleanup must be prioritized based on risk. Not everything should be deleted immediately. Some components are referenced by integrations, reporting, or automation and require careful investigation. Others are unused but historically important and should be archived first. A third group — clearly unused metadata — can be safely removed after verification. I treat cleanup as a structured backlog with planned releases rather than random administrative work. 

I almost never delete items right away. Instead I follow a deprecation approach. First I back up the data. Then I rename the field with a “XXXTOBEDELETED” suffix, remove it from layouts, and eliminate references in automation and reporting. I wait 30 to 90 days. If no one notices and no process fails, the field can then be permanently deleted. This waiting period prevents most cleanup disasters. 

However, cleanup alone does not solve the underlying problem. Technical debt in Salesforce is usually not caused by the platform; it is caused by process. Without governance, the system will gradually return to the same state. 

After stabilizing the org, I establish guardrails. All changes go through sandboxes and version control. Naming standards are defined. New fields require justification and documentation. Automation strategies are standardized, typically favoring Flow and avoiding overlapping logic. Documentation is maintained in a shared space explaining the purpose of fields and automation. These practices prevent uncontrolled growth. 

Even with governance, maintenance must continue. I recommend quarterly health reviews. Review new metadata, monitor automation failures, and watch field growth. Salesforce should be treated like a living system that requires ongoing care rather than a project that is completed once. 

Cleaning a 5-7-year Salesforce org feels overwhelming at first, but it is manageable with a methodical approach. Start with visibility, prioritize carefully, make controlled changes, and enforce governance. When done correctly, the benefits appear quickly. Pages load faster, reporting becomes reliable, users regain confidence in the system, and admins are no longer afraid to make improvements. 

Most importantly, Salesforce becomes something the business trusts again instead of something it works around.