Inheriting a Legacy Salesforce Org: The First 90 Days Playbook

💬 In plain words: Joining a company with a 10-year-old Salesforce org is like corporate archaeology. Nobody knows why half the automation exists, test coverage is dangerously thin, and every deployment is terrifying. The proven playbook for surviving this? First, LOOK (inventory and metrics). Then, STABILIZE (fix tests, add monitoring, stop the bleeding). Finally, MODERNIZE step by step. Never attempt a massive "big-bang" rewrite.

📌 Example: Day 1 at the new job: you inherit a 10-year-old org with 40 custom triggers and weekly production crashes.

Month 1: Run Salesforce Optimizer, dig through incident logs, and rank the highest risks.
Month 2: Get the failing tests back to green, add error logging, and kill the top 3 recurring bugs.
Month 3: Pitch a gradual modernization roadmap to leadership. Never use the word "rewrite."

🔑 Key Points

• Audit Before You Act: Rely on data from Optimizer and incident logs, not opinions, to understand the system.
• Fix the Foundation First: Do not touch business logic until you have green tests and deployment gates in place.
• Target High-Value Wins: Fix the code that breaks the most often to build trust with the business quickly.
• Strangler Pattern: Retire legacy code piece-by-piece by routing new logic into clean services, rather than attempting a high-risk total rebuild.

🎬 Real-Life Example: The Fix That Broke Friday

The Scenario: A new architect inherited a messy, ten-year-old org. To clean things up, they deleted an "obviously redundant" trigger in week one.

The Old/Bad Way: The trigger looked entirely dead. No tests referenced it, and nobody in the company could explain what it did.

Why this is bad: It turned out that "dead" trigger fed a vital nightly commission calculation job by setting a very specific field. Finance only found out when payroll failed on Friday. In an undocumented org, an "obviously redundant" change is just a guess wearing a confident disguise.

The New/Good Way: Spend your first 30 days strictly observing. Run dependency checks, review logs, and listen to users. Add tests and a deployment gate. Only after the org is stable do you change the design.

The Payoff: Nothing gets deleted without a test proving its exact function. The order matters: look, stabilize, then change.

🧠 Look, Stabilize, Then Change: Spend your first 90 days taking inventory and listening. Add tests and guardrails next. Only then do you actually change how things work.

📅 The 90-Day Playbook Concept

Phase 1: Days 1 to 30 (Discovery, without judgment)

• Run Salesforce Optimizer and perform a deep metadata analysis. Identify the objects, the automation clustered on each object, the true code coverage, and the API versions.
• Map your integration landscape: document who calls into Salesforce, and what external systems Salesforce calls out to.
• Read the incident history and interview the humans. Admins and power users know where the bodies are buried.
• Your final deliverable for Month 1 is a risk-ranked map based on facts, not opinions.

Phase 2: Days 31 to 60 (Stabilize)

• Get the failing and flaky Apex test classes back to green.
• Add proper error logging and monitoring to the areas of production that are currently "dark" (failing silently).
• Implement a deployment gate (like a staging sandbox validation) if one does not already exist.
• Fix the two or three worst recurring incidents. These are highly visible wins that will buy you trust with the business.

Phase 3: Days 61 to 90 (Modernization Roadmap)

• Present a modernization roadmap that the business actually signs off on.
• Plan to consolidate automation (e.g., migrating old Workflow Rules/Process Builders to Flow, or consolidating multiple triggers into one orchestrator).
• Use the strangler pattern for the worst legacy code: build new logic in clean services, route traffic slowly, and retire the old paths gradually.
• Create a "technical debt register" with clear business costs attached to each item.

⚠ Anti-Patterns to Avoid: Interviewers and CTOs watch out for red flags. Never suggest rewriting everything from scratch (it is a multi-year gamble). Do not mass-delete automation you don't fully understand yet. And never waste time criticizing your predecessors—focus on fixing the system instead.

🧭 360 Card — Inheriting a Legacy Org

• Rule: Look, stabilize, then change. Ninety days, three phases, in that exact order.
• Gain: You earn the political capital to change things by first proving you understand what is already there.
• Price: Going 30 days without fixing anything is politically difficult when everything around you looks broken.
• Limits: The first 30 days are strictly for looking (Optimizer, logs, listening). Days 30–60 add guardrails (tests, logging, gates). Only after day 60 do you change the design.
• Mirror: Fixing the "worst thing" in week one feels decisive, but usually breaks an undocumented process and spends your credibility early.
• Later: Rank the technical debt by (Incident Cost × Change Frequency). Fix what breaks often and changes often first.
• At Volume: Rebuild trust through boring, predictable releases. A run of quiet, dull deployments is your best argument for a promotion.

❓ Core Q&A

Q: You inherit a 10-year-old org with 40 triggers, workflow rules everywhere, 68% test coverage, and weekly production incidents. What are your first 90 days?

🎯 Say this first: 30 days: inventory and a risk map. 30 days: stabilize by adding tests, logging, a deployment gate, and killing the top incidents. Then, deliver a step-by-step modernization roadmap using the strangler pattern. Never propose a big-bang rewrite.

A: In the first month, I measure but do not touch. I run Salesforce Optimizer and dependency tools to see the metadata reality. I interview power users and review incident logs to find out where it actually hurts. The output is a risk-ranked inventory.

In the second month, I stabilize. I get the test suite back to green with real assertions on the riskiest paths. I add error logging where failures are invisible, enforce a simple deployment gate, and fix the top three recurring bugs to earn quick wins.

In the third month, I pitch the roadmap. We move to one trigger orchestrator per object. We strangle the worst legacy services: running new code beside old code, and gracefully retiring the old. The org processes revenue today—my job is to improve it while it keeps running. It is like renovating a house you are actively living in.

🚀 Scenario-Based Follow-ups

Q1: How do you decide what to fix first when everything looks bad?

A: Rank the technical debt by incident cost multiplied by change frequency. Code that breaks often AND requires frequent changes gets fixed first because that is where the risk compounds. Stable, ugly code that nobody touches goes LAST—no matter how offensive it looks to a developer. Refactoring untouched code is pure risk with zero business payoff. Put this all in a debt register so the ordering becomes an evidence-based conversation, not an opinion war.

Q2: The business is nervous and says, "Every time IT touches the org, something breaks." How do you rebuild confidence?

A: Confidence is rebuilt by boring releases. Start with a safety net: tests that actually assert logic, staging validation, and monitoring that catches errors before users do. Then, deliberately ship a series of small, announced, highly successful changes. Prioritize predictability over heroics. Once you have a quiet quarter of flawless deployments, the business will shift from "don't touch it" to "what else can we improve?"

Q3: What is the best way to handle overlapping Workflow Rules and Process Builders in a legacy org?

A: Do not just blindly convert them one-to-one using the migration tool, as that carries over the messy architecture. Instead, map out the automation per object. Build a streamlined Record-Triggered Flow framework (Before-Save for same-record updates, After-Save for related records/actions). Gradually recreate the legacy automation inside this new Flow structure and deactivate the old rules piece-by-piece in a sandbox. Test heavily before deploying.

🔗 Connecting the Dots

Follow-up for you: Imagine you are starting on Monday. What is the very first diagnostic tool you plan to run on your newly inherited legacy org?