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.
Inventory Before You Move
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.
Data: Clean or Die
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:
"VIP" → "Premium" (mapped via Salesforce data loader)
"Retailer" → "Wholesale" (requires manual override in 500+ records)
"Gold" → "Premium" (automated, but flagged for review)
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.
Custom Code: Harmonize or Scrap
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.
Test Like You’re Paying for It
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.
The Real Win: One Source of Truth
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.
📚 Recommended Resource: Salesforce for Dummies — great for anyone learning Salesforce.
📚 Recommended Resource: NIST Cybersecurity Framework Guide — great for anyone security frameworks.
Need a second opinion on your Salesforce org? Request a diagnostic.
Top comments (0)