Consolidating Three CRMs in a 36-Hour Cutover
Meridian Industrial is consolidating three legacy CRMs after acquisitions. The target org must load 420,000 accounts, 1.1 million contacts, 90,000 active leads, and 350,000 opportunities, plus opportunity products. Source systems overlap heavily: one customer may appear as 'ACME Corp', 'Acme Corporation', and 'ACME-Corp'. Each source has its own account ID; there is no common key. Cutover is a 36-hour weekend window. Meridian has a full sandbox, Data Loader, and two admins; no middleware budget. The sales team will not tolerate duplicate account lists, and finance needs opportunity history preserved. The org already has duplicate rules and matching rules, but they were configured for manual entry.
1. Recommend the load sequence and key strategy for the migration. What must happen before the 36-hour window?
Read the worked answer
Before cutover, build a staging database outside Salesforce. Standardize company names, addresses, phone numbers, and websites; map each source account to one master account; and assign a new Master_Account_ID__c external ID. Keep Source_System__c and Source_ID__c on each record for traceability. Create composite source keys if you need to upsert later.
The load order is: users, queues, record types, products, and price books first; then accounts; then contacts linked by account external ID; then opportunities linked by account external ID; then opportunity products linked by opportunity external ID and price book entry ID; then active leads. Do not load opportunities before accounts or opportunity products before products.
Use Data Loader in bulk mode and run at least two full-volume rehearsals in the full sandbox. Measure actual load times and API consumption. Deactivate or bypass nonessential validation and automation with a controlled switch, and defer sharing calculation until after the load. The 36-hour window should be for final delta loads and validation, not for discovering mapping errors.
2. How should Meridian handle duplicates within and across the three sources? What role should matching rules and duplicate rules play?
Read the worked answer
Do the primary deduplication before loading. Use normalized name, website domain, address, and phone to group candidates; for a one-time migration, a staging database or spreadsheet with fuzzy matching is more practical than relying on Salesforce duplicate rules alone. Define a survivorship rule: which source wins for name, address, owner, and financial fields. Merge at the master level and retain source keys.
Matching rules define what Salesforce considers a duplicate; duplicate rules decide what happens when a user or API creates one. Meridian's existing rules were tuned for manual entry and may be too loose or too strict for 1.1 million contacts. Test them in the full sandbox with real volume. Do not assume they will catch cross-source duplicates that were never normalized.
After the load, use duplicate rules to prevent new duplicates, starting with alert rather than block until false positives are understood. Run a duplicate report by matching rule weekly during hypercare. If duplicate rules block Data Loader, adjust the rule actions or load only pre-deduplicated records; always test the exact API path.
3. What validation and cutover controls would you put in place to protect finance and sales?
Read the worked answer
Validate at three levels. Record counts: source-to-target counts by object and source system. Financials: total opportunity amount, open pipeline by stage and close date, and closed-won revenue by period compared with legacy. Business samples: top 100 accounts, 50 strategic opportunities, and a random sample per region reviewed by sales ops.
Check for orphan contacts, opportunities without accounts, opportunity products without price book entries, missing owners, and accounts still assigned to the migration user. Run a duplicate report and a sharing-access test for a rep in each region. Confirm that legacy created dates, close dates, and amounts are preserved in standard or custom fields; standard field history does not import, so finance must agree on what history means.
Cutover controls: freeze legacy edits, run final delta load, recalculate sharing, run smoke tests, then open access. Keep a rollback plan using external IDs to identify the migration batch. Schedule hypercare reports for duplicates, ownership, and pipeline totals for the first two weeks.