The Short Answer
The three options aren't on the same continuum. Repair addresses a symptom, Refactor changes an implementation without altering behavior, and Rebuild changes the underlying model. The decision hinges on one question: Is the problem in how things were implemented, or in what was defined from the start?
If the data model is sound but the pain point lies in complex automations and convoluted permissions, that's a Refactor. If the same object serves three conflicting processes and can't be reported on, that's a root issue, and then Rebuild becomes a consideration.
Four Decisive Tests
| Test | Points to Refactor | Points to Rebuild |
|---|---|---|
| Data Model | Sound, suffers from an excess of fields | Objects serving conflicting purposes |
| Source of Pain | Performance, duplicated automations | Inability to report or extend |
| Scope of Affected Users | Partial, isolatable | Cross-cutting across all processes |
| Cost of Re-testing | Can test a single area | Every change requires full regression |
Three rows pointing in the same direction are sufficient for a decision. A split among the rows usually means the problem is more localized than it feels.
Why Rebuild is More Expensive Than Estimated
The typical estimate counts only the reconstruction itself. It almost always skips four elements: historical data migration with all accumulated exceptions, re-building integrations, each of which is agreed upon with a third party, a parallel run period where both systems live, and complete re-training for all users.
In practice, these four often constitute more than half the cost. An organization considering a Rebuild that hasn't priced them is comparing apples to half an orange.
The Practical Path: Gradual Replacement
Even when a Rebuild is decided, executing it as a "stop-and-replace" project is inherently risky. The path that works is a domain-by-domain replacement:
- Build the new model alongside the old - new objects, without touching existing ones.
- Migrate one complete process - with its users, data, and reports.
- Deactivate the old equivalent - this is the step most organizations delay, which turns the project into a double effort.
- Repeat until the old system is empty.
Step three is the test. A system where both the old and new live in parallel for a full year has increased costs, not reduced technical debt.
What Must Change Regardless
Both paths fail if the change mechanism remains as it was. Minimal governance – who approves model changes, what mandatory testing is required before deployment, and who owns each domain – is the prerequisite to prevent returning to the same point. Prioritizing the debt itself is detailed in Prioritizing Salesforce Technical Debt, and early warning signs in 8 Signs for a Salesforce System Upgrade.
Summary
The choice isn't between "fixing" and "starting over," but between fixing implementation and fixing definition. In most cases that look like a Rebuild, a sound data model is hidden beneath a decade of automations – and that's cleaned in waves, not with a wipe-out.