Contact data migration and synchronisation

The business wanted to bring customer conversations from WhatsApp, Messenger, SMS, and email into one service platform. Before that could work properly, it needed a dependable contact list.

The existing CRM contained roughly 40,000 to 50,000 worker records, but a row did not represent a person alone. It represented a person in a particular employment or engagement. When somebody left and later returned, the CRM could create another row for the same individual, even when the underlying person and pay arrangement had not changed.

Copying those rows directly into the new platform would have created duplicate contacts, fragmented conversation histories, and an increasingly unreliable support directory. I built a migration process that resolved repeated records into person-level contacts, then turned it into a permanent bridge between the two systems.

The source and destination described different things

The source CRM structure made sense within its original operational context. Each row combined information about a worker with information about their current engagement. That allowed the business to manage the relationship as it changed over time.

The customer-service platform needed a different model. Its primary unit was the person who might start a conversation on any supported channel. Several source rows could therefore belong to one destination contact.

This was not simply a matter of deleting bad duplicates. The repeated rows often described legitimate employment history. The migration had to preserve the distinction between those records while deciding which of them belonged to the same human being.

Resolving people across repeated records

I wrote deterministic matching and consolidation rules using the identifiers and contact information available in the source data. The process grouped records that could be linked confidently, selected the usable person-level details for the destination, and kept uncertain matches out of automatic consolidation.

That separation was important. Overly loose matching could merge two different people, while overly strict matching would reproduce the source duplication in the new platform. The rules needed to be explainable, repeatable, and safe to run across tens of thousands of records.

The resulting transformation converted an employment-centred dataset into a contact-centred one without pretending the two systems shared the same data model.

Migrating the contact base

The initial migration processed the full CRM contact population, applied the matching rules, and created a clean set of person-level contacts in the multichannel platform.

Because the transformation was captured in code, the same rules could be applied consistently across the full dataset instead of treating the migration as a one-off spreadsheet cleanup.

The work was coded specifically around the organisation's data and business rules. It did not rely on an opaque deduplication tool making unreviewable guesses about identity.

Repeated employment records were resolved into one person-level contact, then kept aligned as the source CRM changed.

Building the permanent bridge

A clean initial import would only remain clean until the CRM changed again. New workers would join, existing details would be updated, and returning workers could produce more employment records.

I therefore extended the migration into an ongoing synchronisation process. At regular intervals, the bridge read new and changed source records, applied the same identity rules, and either created a new destination contact or updated the existing person-level record.

This kept the CRM as the operational source while giving the service team a dependable contact layer for conversations across channels. The business did not have to choose between replacing its established system and accepting a customer-service platform full of duplicates.

The outcome

The project turned a difficult source structure into a usable contact base for multichannel support and made that transformation sustainable over time.

Its value was not merely moving records from one product to another. It was translating between two different business models, defining what counted as the same person, encoding those decisions as repeatable rules, and keeping the result aligned as the source continued to change.

That is what makes a reliable data migration: understanding what the records mean before deciding where they should go.

The organisation, platform provider, contact records, and identifying implementation details have been withheld.