Refactoring a Legacy Salesforce Org Without Breaking Production
You inherited a 10-year-old Salesforce org and everything is fragile. The temptation is to rebuild. The right answer is usually to refactor, in a specific order that keeps the business running.
You inherited a Salesforce org that has been alive for a decade. There are 400 custom fields per account, three overlapping automations on every save, and an Apex class named ProcessStuff that nobody dares touch. The temptation is to declare bankruptcy and rebuild. The right answer is almost always to refactor, but in a specific order that keeps the business running. Here is the playbook.
Rebuild vs Refactor: The Honest Check
Rebuild only if two of these are true: the object model is fundamentally wrong, more than 60% of code is dead or misused, or the sponsor has fresh political capital. Otherwise, refactor. Rebuilds cost 3x refactors and carry 3x the adoption risk.
The Refactor Order That Works
- Freeze net-new customization for 4 weeks. Nothing new until baseline is understood.
- Score technical debt. Run the 8 debt indicators. This is your map.
- Delete before you refactor. Every unused field, report, Flow, and Apex class deleted is one less thing to migrate.
- Consolidate automation. Migrate Process Builder and Workflows to Flow, one object at a time. See our Flow migration playbook.
- Rebuild the object model surgically. Only where it is genuinely wrong. Introduce new custom objects rather than reshaping standard ones in place.
- Rewrite Apex last. Cheap classes first, monolithic complex ones last, with test coverage every step.
The "Do It Alongside" Pattern
Refactoring a live org rarely means "stop and rebuild." It means: build the new version alongside the old, dual-write while both run, migrate users when the new path is proven, retire the old artifact. Slower than a rewrite in the sandbox, but it never takes production down.
The Regression Test Set You Cannot Skip
Before any refactor step, capture: the top 20 reports (screenshot + row count), the top 10 Flow paths (input → expected output), and the API response for the top 5 integrations. Re-run after each change. This one habit prevents 80% of production incidents.
When to Bring in Outside Help
- You are the only person who knows the org.
- Original documentation does not exist.
- Every deploy takes hours and fails half the time.
- The sponsor is losing patience with "no visible progress."
Two of these = a red flag. Three = a rescue conversation. See our rescue guide.
Regional Notes
- EU: if refactoring changes data flows, refresh the record of processing activities (ROPA). See GDPR guide.
- US & Canada: align refactor waves with SOC 2 audit cycles for maximum efficiency.
Frequently Asked Questions
How long does a refactor take?
Small org: 2–3 months. Mid-market: 4–8 months. Complex enterprise: 9–18 months, phased.
Can we refactor while running new projects?
Yes, but cap new customization at 20% of dev capacity during the refactor. Otherwise the debt grows faster than you shrink it.
How do we sell this to leadership?
Translate debt into risk: outage probability, hours lost per week to workarounds, forecast accuracy tax. A refactor that avoids one outage pays for itself.
Do we need to freeze all releases?
Not all, only net-new customization during the initial baseline. Bug fixes and compliance ship normally.
Scope a Fixed-Price Refactor
Our Salesforce audit ends with a refactor roadmap: what to delete, what to migrate, what to leave alone, in phased releases. Book a 30-minute call.
If this sounds like your CRM, let's look at it together.
Thirty minutes, no deck, no pitch. You leave with a diagnosis either way.