Mergers don't come with a Salesforce "merge" button. I've guided 12 enterprise consolidations across healthcare, retail, and manufacturing—each time, the real work started with a brutal truth: your orgs are islands. Not just with data, but with custom objects, security models, and business logic. Here’s how to cut through the noise.
Don’t assume you know what exists. In a recent healthcare merger (2023), we inherited 4 Salesforce orgs with overlapping patient management tools. One org had a custom "Patient Journey" object; another had "Care Path" with identical fields. We ran this SOQL across all production orgs to find duplicates:
SELECT Id, Name, SObjectType FROM EntityDefinition WHERE SObjectType LIKE '%Patient%' AND IsCustom = true
Result: 37 custom objects across 4 orgs. We documented *all* field mappings, validation rules, and automation before touching a single record. Skipping this led to a $200k rework in a manufacturing client when we tried to migrate a custom inventory tracker without checking if it conflicted with the acquirer’s existing module.
Migrating messy data is like shipping a dumpster to a new house. In a retail merger, the acquired company used "Customer_Type__c" with values like "VIP," "Gold," and "Retailer." The parent company used "Customer_Segment__c" with "Premium," "Enterprise," and "Wholesale." We built a mapping spreadsheet *before* migration:
We deleted 12,000 inactive accounts using this SOQL to identify dead records:
SELECT Id, Name FROM Account WHERE IsDeleted = true AND LastModifiedDate < LAST_N_DAYS:365
Zero cleanup = zero trust in the new org. Always purge before migrating.
Don’t let "it worked here" become your new nightmare. At a financial services merger, both companies had custom Apex triggers on Account. Trigger A updated "Risk_Score__c" based on lead source; Trigger B updated "Credit_Rating__c" based on account type. We deleted both and built a single trigger with conditional logic. Why? Because merging the triggers caused a 15% error rate in lead processing during UAT.
Rule: If two orgs have the same business rule but different code, rebuild it *once* in the target org. Never merge code—rewrite it to be universal.
Run a "fake" migration on a sandbox *first*. In the healthcare example, we copied 5% of production data to a sandbox and ran all critical user journeys: scheduling appointments, billing, and EHR integration. We caught a broken API call to the billing system that would have halted 200+ daily transactions. Testing in production? That’s a career-ender.
Post-consolidation, we didn’t just merge orgs—we built a shared data model. The retail client now uses one "Customer_Segment__c" field for all segments across regions. The healthcare client has a single Patient Journey object for all care types. This isn’t "nice to have"—it’s how you avoid paying $500k/year in redundant admin work.
Consolidation isn’t about moving data—it’s about building a single source of truth that *scales*. If your current org is a patchwork of legacy decisions, you’re not just consolidating; you’re setting up your next failure. Stop patching, start building.
Ready to see how healthy your Salesforce environment really is? Get a free, no-strings health scan—it’ll pinpoint the exact risks slowing your consolidation. No fluff, just what you need to fix.