Data migration sounds technical. And it is. But the real challenge is rarely about the technology: it’s about trust. Trust that the data built up over years will still be accurate after a system switch. That nothing gets lost. That the transition doesn’t mean starting over.
The organisation we did this project for understood that perfectly. They had six years of customer data in a legacy CRM. Contract history, correspondence, purchasing behaviour, support tickets: everything was in there. And they wanted to move to Salesforce without leaving that history behind.
The situation: a legacy system reaching its limits
The old system had served them well: but it no longer scaled. Integrations with other tooling were cumbersome, the interface was dated and the vendor had no clear development roadmap. At the same time, the dataset was substantial: more than 15,000 contact records, thousands of related activities and an extensive contract history.
The decision to switch had been made. The question was: how do you do that without disrupting daily operations and without losing data that took years to build?
The approach: understand first, migrate second
We didn’t start with exporting data. We started with asking questions. Which data is operationally critical? Which is historically valuable but not needed day-to-day? What can be archived? Which fields in the old system have an equivalent in Salesforce, and which don’t?
That analysis produced a three-tier migration plan:
- Critical data: active accounts, contacts, current contracts and open activities: fully migrated with high priority and multiple validation passes.
- Historical data: closed contracts, resolved cases and correspondence: migrated as an archive, accessible but not active in workflows.
- Legacy data: outdated records with no operational value: documented and retained outside Salesforce, anonymised or deleted in accordance with GDPR policy.
We then built an automated migration pipeline: data was transformed into the Salesforce data model, loaded into a sandbox environment and thoroughly tested by both our team and the client’s internal users.
Data quality as a prerequisite
One of the biggest pitfalls in data migrations is carrying over existing mess. Outdated addresses, duplicate contacts, missing relationships: if you migrate those without cleaning them up first, you end up with a new system full of old problems.
We ran an extensive data quality process before migration: deduplication of contact records, validation of email addresses, repair of missing relationships between accounts and contracts. It took time: but it delivered a clean starting position in Salesforce.
Go-live: phased and controlled
The actual switchover was done in phases. First a subset of users: early adopters: who started working in Salesforce while the old system remained active. This allowed us to identify and resolve issues early without affecting the whole organisation.
After three weeks of parallel operation: with daily synchronisation to prevent divergence: we switched over completely. The old system went into read-only mode for six months as a safety net. After that, it was decommissioned.
The result: a new system with a rich history
The migration was completed within the planned eight weeks. No data loss, no critical errors and: perhaps most importantly: no panic among end users. The data they had built up over years was simply there. In a different place, but recognisable and complete.
What we also achieved:
- 15,200 contact records migrated, 12% deduplicated or corrected
- Six years of contract history accessible in Salesforce
- ERP and email marketing platform integrations configured from day one
- Users could work independently from go-live without weeks of adjustment time
What you can take from this
A data migration isn’t a copy-paste operation. It’s an opportunity to bring order to years of accumulated information: and to start a new system on a clean footing. But that only works if you take the time to understand what you have before you start moving it.
Are you considering a system switch, or do you have data sitting in a legacy environment? We’re happy to think through what’s needed for a migration that actually works.