Taking over a website or a Salesforce org someone else built is a specific kind of uncomfortable. You’re responsible for a system you didn’t design, under pressure to understand it quickly, often with the person who built it long gone and no documentation to fill the gap. The instinct is either to blame the previous team or to assume everything’s fine and start making changes. Both instincts cause problems.
Here’s a calmer, more useful approach: a structured, no-blame audit that establishes what you’re actually working with before anyone commits to a scope or a number.
Why inherited systems are specifically hard
A system you built yourself carries its history in your memory — you remember why a particular field exists, why an integration was built a certain way, what tradeoff was made under a deadline. An inherited system has none of that context attached. Every unusual decision looks like it could be either a deliberate, load-bearing choice or an accident, and you can’t tell which without investigating — which is exactly why guessing (or assuming the worst about the previous team) is a worse starting point than a genuine review.
Documentation review
Start with whatever documentation exists, however incomplete — README files, an admin’s notes, ticket history, even old emails describing why something was built a certain way. This rarely tells the whole story, but it’s the fastest way to rule out easy questions before spending time investigating something that was already explained somewhere.
Why the instinct to start fixing immediately backfires
There’s often real pressure to show progress fast on an inherited system — a new hire or a new agency wants to demonstrate value, or a business owner wants visible momentum after what may have been a difficult transition from a previous provider. That pressure is understandable and usually counterproductive. Changing something before understanding why it was built that way risks breaking a dependency nobody documented, and it forecloses the option of learning something important that only would have surfaced through a proper review. A week or two spent understanding the system genuinely is faster, in total, than fixing something twice because the first fix was made without full context.
Access review
Before anything else, establish who actually has access to what: hosting, domain, Salesforce org, any third-party integrations, and whether the business itself owns those accounts or whether they’re still under a former employee’s or agency’s control. This is often more urgent than it sounds — access gaps are a real operational risk, not just an inconvenience, and they’re worth resolving before diving into technical review.
Architecture review
For a website: what’s the actual technical foundation — theme, key plugins, hosting environment — and how customized is it from a standard setup. For a Salesforce org: what objects and automation actually exist, and whether the configuration reflects deliberate design or years of incremental patches layered on top of each other. This review is diagnostic, not evaluative — the goal is understanding what’s there, not judging whether it was built well.
Integrations
What else does this system talk to, and how? Inherited systems often have integrations nobody remembers exist — a Zapier connection quietly moving data somewhere, an API key with access that was never revoked. Mapping these is essential before making changes, since disabling or modifying something can break a connection nobody knew was load-bearing.
Data quality
How reliable is the data actually in the system — duplicate records, incomplete fields, information that’s technically present but practically unusable? This matters because data quality problems compound: a plan built on the assumption that existing data is clean will go sideways the moment that assumption turns out to be wrong.
Technical debt
Distinguish between debt that’s currently costing something (a slow site, a manual workaround someone does weekly, an integration that breaks periodically) and debt that’s stable but unaddressed (an outdated but functioning plugin, a data model that’s not ideal but works). The first category is usually worth prioritizing; the second can often wait.
Risks
A written list of what could go wrong and how likely it is — an unsupported plugin that could break on the next WordPress update, a Salesforce automation nobody fully understands that touches critical records. Naming risks explicitly, even ones that aren’t being addressed immediately, is more useful than discovering them later.
Quick wins
Alongside the larger picture, a good inherited-system audit usually surfaces a handful of small, low-risk fixes that deliver visible value fast — a broken form, an obviously misconfigured automation, a security update that’s overdue. These build confidence and buy time for the larger decisions to be made properly instead of under pressure.
Prioritization
Everything above converges into a ranked list: what needs attention immediately, what can be planned for the near term, and what’s stable enough to leave alone for now. This is the actual deliverable of a no-blame audit — not a verdict on the previous team, but a clear, current picture of what you’re responsible for and what to do about it, in order.
How long a proper audit takes
For a website or a Salesforce org of moderate complexity, a structured audit covering documentation, access, architecture, integrations, and data quality typically runs one to two weeks — similar in scope to the discovery process behind any new engagement, just aimed at understanding an existing system rather than planning a new one. Resist the pressure to skip straight to fixes before this is done. The most expensive mistakes with inherited systems come from acting on an assumption that turns out to be wrong — disabling something that looked unused but wasn’t, or committing to a scope based on a data quality estimate that the actual data didn’t support.
Why “no-blame” matters, practically
Decisions made under an earlier deadline, budget, or set of requirements often look wrong with hindsight and full context, without having been wrong at the time. Treating an inherited system as a puzzle to understand — rather than a problem to assign fault for — produces a better audit and a better plan, because it keeps the focus on what’s actually there instead of on relitigating decisions nobody involved can fully explain anymore.
How we approach this
This is close to how we start every engagement involving a system we didn’t build — the same principle behind our answer to “can you take over a site someone else built?”: yes, starting with an audit, so both sides know the actual condition of the codebase and data before committing to scope. If you’ve recently inherited a website or Salesforce org and aren’t sure what you’re actually working with, a conversation is a reasonable place to start.