Salesforce Org Separation
Split a combined Salesforce org into two fully independent instances when one company became two — separating accounts, contacts, opportunities, campaigns, custom objects, automations, and third-party integrations without data loss.
When Builder's Vision split into two independent companies, every record, automation, and integration had to follow the right entity into the right org. Nothing about Salesforce's native tooling makes this easy — there's no "export this half of your data" button.
The Challenge
The risks were simultaneous and compounding: records belonging to the wrong company could create legal and operational problems; automations built against shared IDs would silently fail post-split; and third-party integrations still pointed at the original combined org had to be reconfigured without disrupting live operations.
The scope covered Accounts, Contacts, Opportunities, Campaigns, and several custom objects — plus all the automation logic and connected app credentials layered on top of them.
The Approach
Before touching anything, I mapped record ownership across every object category. Data was cleaned and tagged first, then migrated in dependency order — standard objects before custom, records before relationships, metadata before integrations. Each step had a validation checkpoint before the next began.
Automation logic was audited against post-split field and ID references and rebuilt where references would break. Integrations were re-pointed and tested in sandbox before the production cutover window.
Outcome
Both companies launched with clean, fully operational Salesforce instances. No records were misrouted, no automations fired against phantom references, and no integration lost data during the transition. The process documentation I produced became the internal reference for any future org-level changes.