Why divestiture audits fail
Most Salesforce orgs that have been running for more than five years have accumulated significant undocumented complexity. Sharing rules that were correct once but haven't been reviewed since. Permission sets with dangerous grants that were assigned temporarily and never removed. Schema that grew organically — custom fields added per project, never rationalised.
When a divestiture is announced, someone needs to answer: what data belongs to which entity? What integrations, contracts, and licences are in scope? What breaks on Day 1 if nothing is done? That question is usually asked too late, by people who don't have the tooling to answer it quickly.
The methodology here addresses that directly. The output is an inventory with risk ratings and clear owners, produced fast enough to inform programme planning rather than react to it.
Principles
- Read-only. No DML. No metadata deploys. No changes to the org. The audit runs against a sandbox copy wherever possible.
- Staged. Each stage is independent. A failure in Stage 3 doesn't invalidate Stages 1 and 2. Re-run the failing stage once the issue is resolved.
- Machine-readable outputs. Each stage produces a JSON file alongside the human-readable report. The JSON is the source of truth for Stage 5's master report assembly.
- No bulk PII. COUNT and GROUP BY everywhere. Investigate anomalies by querying targeted record sets, not bulk exports.
- Reproducible. Every finding includes the SOQL or Tooling API query that produced the evidence. Anyone can re-run it.
The five stages
| Stage | Focus | Typical run time |
|---|---|---|
| S1 — Org fingerprint | Users, profiles, permission sets, installed packages, connected apps, org limits | ~1 min |
| S2 — Security deep dive | Sharing rules, dangerous permission grants, admin population, guest users, field-level security on BU-sensitive fields | ~3–5 min |
| S3 — Data quality | Record counts, BU field distribution, inactive-owner records, duplicate rates, custom field population rates | ~5–10 min |
| S4 — Configuration and technical debt | Apex test coverage, trigger density, validation rules, record types, flow and automation inventory | ~5–10 min |
| S5 — Master report | Assembles S1–S4 JSON into a single findings report with risk register and remediation recommendations | <1 min |
The shared library handles authentication, SOQL pagination, Tooling API calls, and output formatting. Each stage script imports the library and focuses on its domain. The whole thing is roughly 1,500 lines of Python across six files.
What to look for
Security (P0 priority)
Check sharing rule criteria for cross-BU record exposure first, before anything else. A misconfigured criteria-based sharing rule can expose records across a business unit boundary silently. This is the most common critical finding in multi-BU orgs and it is often live on arrival.
Other P0 candidates: admin population well above benchmark (5 is standard — anything over 15 needs justification), permission sets with Modify All Data or Login As User still assigned, OWD settings on sensitive objects set to ReadWrite with no compensating controls.
Data quality (P1 priority)
The migration-blocking findings are almost always in data quality. The most common: a business unit classification field on Contact (or equivalent) that has a high null rate. If 90%+ of your Contact records have no BU assignment, they cannot be automatically migrated to the correct successor org. That's a programme decision, not a technical fix — it needs a data owner and a budget.
Also check records owned by inactive users. These represent unmaintained data with no current steward. Volume matters for migration planning.
Schema (P1 priority)
Custom field counts on core objects. Salesforce has hard limits. Objects approaching 800 custom fields are close to the ceiling, and schema that dense invariably contains a high proportion of zero or near-zero population fields. These need a rationalisation decision before migration.
Validation rules that reference RecordType names, Profile names, or IDs by string will break if those names or IDs differ in the target org. Enumerate them explicitly.
Configuration inventory (P2 priority)
Reports and dashboards — folder sharing may cross BU boundaries; migration scope is undefined until you know. Managed packages — BU scope and re-licensing requirements must be mapped. Connected apps and integration users — apps scoped to the departing entity must be re-registered. API/integration users — none typically have BU scope recorded anywhere.
The findings format
Each finding is a numbered markdown document. The format is fixed:
- Reference: R01, R02 … Rn
- Priority: P0 (Critical) / P1 (High) / P2 (Medium) / P3 (Low)
- Domain: Security / Data / Schema / Configuration / IAM / Integration
- Finding: One sentence, factual, no interpretation
- Evidence: The SOQL query and its result
- Risk: What goes wrong if this isn't addressed before Day 1
- Recommended action: Specific, with a named owner team
The master report assembles all findings into a single document with a risk register summary table. The steering group gets the summary. The technical teams get the full numbered docs.
Pending decisions
Some findings can't be remediated until a programme decision is made. These should be documented explicitly with options, owner, and a decision-by date — because without them, the remediation teams are blocked.
Common pending decisions in a multi-BU divestiture:
- Migration architecture: does the departing entity get a new org, or does it retain the current org while the remaining entity migrates out?
- Shared data model: are contacts, accounts, or other objects genuinely shared by design, or do they need retrospective BU classification?
- Apex coverage path: delete dead classes first (faster path to deployment unblocking) or write tests immediately (safer)?
- Field rationalisation: which zero or low-population fields are excluded from migration scope?
What this produces
A complete picture of the org — security posture, data quality, configuration debt, divestiture risk — produced quickly enough to inform programme planning. The methodology is the same whether the org is 3 years old or 15: read-only, staged, machine-readable outputs, reproducible queries, actionable findings with clear owners.
The accumulation of complexity in large Salesforce orgs is normal. What isn't normal is having an inventory of it with numbered findings before the programme steering group asks for one.
Need this audit run on your org? Talk to us.