Skip to content
Notifications
Clear all

Rolled out Freshsales to 50 users - what broke during data migration

2 Posts
2 Users
0 Reactions
5 Views
(@devops_not_grunt)
Reputable Member
Joined: 4 months ago
Posts: 159
Topic starter   [#1314]

So you're planning a CRM migration? You've read the white papers, sat through the vendor's "seamless migration" demos, and maybe even bought into the promise of AI-powered field mapping. Let me tell you how that played out for us when we moved 50 sales reps from our cobbled-together HubSpot/Salesforce hybrid into Freshsales.

The core assumption—that a CRM is just a database with a web UI—is where the pain begins. Our legacy data had "interesting" field usage. The `Lead Source` field in one system was a single-select dropdown. In the other, it was a free-text graveyard containing gems like "Google," "word of mouth," and "that conference in 2019." The migration wizard happily mapped them. It did not, however, account for the 15 custom validation rules in Salesforce that blocked records if `Lead Source` wasn't from its approved list. The migration job didn't fail; it just silently dumped 12,000 "invalid" leads into a CSV error report nobody checked until Day 3.

The real spectacle was the contact/account deduplication process. We followed the recommended "fuzzy matching" settings. The algorithm decided that "Mike's Garage" and "Michael's Automotive" were a 92% match and merged them. This attached a key enterprise client's primary contact to a small B2C lead. The sales team discovered this when deal values and contact histories started swapping between accounts. The cleanup query looked something like this:

```sql
-- This was our life for a week. Finding merged record ghosts.
SELECT DISTINCT entity_id, entity_type
FROM merge_logs_audit
WHERE merged_at > '2024-03-01'
AND merge_confidence > 0.85
AND merged_by = 'system@migration';
```

What I wish I'd known? That "downtime" isn't just the cutover window. It's the two-week period where your sales team doesn't trust a single data point. The vendor's pre-sales engineering team showed us beautiful field-mapping UI, but they never mentioned that their API rate limits for the migration job are half of the production limits, turning a planned 4-hour sync into a 14-hour marathon. They also don't tell you that their "smart" email sync will re-send welcome emails to every contact migrated if you don't first find and disable the obscure "Automation" rule buried three menus deep.

The lesson wasn't about choosing the right tool. It was about assuming every piece of data has hidden dependencies, and every "intelligent" feature is just a script with no context. Test migrations with your noisiest, most edge-case users. Not with sanitized data.



   
Quote
(@observability_steve)
Eminent Member
Joined: 4 months ago
Posts: 11
 

The 80/20 rule is exactly right, but that last 20% can take 80% of the migration time. It's a cost sinkhole they never budget for.

We didn't roll back. We let the merge stand as a "beta" instance and ran the migration again with a composite key - company name plus a custom field for a legacy internal ID. Slowed the process down by 40%, but the data was clean.

The real lesson? Your migration monitoring is worthless if it only tracks record counts and completion percentage. You need to instrument the *anomalies* - spikes in duplicate detection, validation failures per user, even manual correction counts post-migration. Otherwise, you're just watching the train wreck in slow motion without any brakes.


latency is not a feature


   
ReplyQuote