Move to a new CRM without losing what you already know about your customers

A migration is risky when it is treated as a copy job. It is safer as a sequence. We begin with an audit: how many records, how many are duplicates, which mandatory fields are blank, which relationships (contact to company, deal to contact) are intact. That audit decides what to clean, what to archive and what to leave behind. Not every old record deserves a place in the new system.

Next comes mapping. Source fields rarely match target fields one to one. A free-text field may need splitting, a status list may need collapsing, and two old pipelines may become one. We document each decision in a mapping sheet you can read without technical help.

We then run a trial load into a test environment, you inspect it, we correct, and we load again. Only then does production load happen, normally over a weekend or a quiet period, with the old system frozen to new edits. Most migrations take 3 to 8 weeks; a large estate with several source systems takes longer, and the audit tells us how much longer.

Arabic creates problems that English datasets do not. The same company can appear as an Arabic name, a transliteration, and an abbreviation. Alef and hamza variants, a different spelling of the same name, and mixed digits (Arabic-Indic and Western) defeat simple duplicate matching. We normalise text for matching without overwriting the original, so people see the name as it was written while the system can still find duplicates.

A CRM migration moves personal data, so the Personal Data Protection Law applies to the move itself. We limit what is copied to what you have a reason to keep, restrict who can touch the extracts, delete working copies when the project ends, and record where the data went. If migration involves a processor outside the Kingdom, the PDPL transfer rules need checking with your legal adviser before we start.

Consent is worth special attention. If your old system recorded who opted out of marketing, that flag must travel with the contact. Losing it is how a company ends up emailing people who asked not to be emailed.

Integration is a design choice, not a plug. The first question is which system owns which data. The CRM usually owns the lead, the opportunity and the sales contact. The ERP or accounting system owns the invoice, the tax treatment and the payment record. In the Kingdom, invoices must meet ZATCA e-invoicing requirements, so the CRM should read invoice status from the system that issues it instead of creating its own copy.

Next is the method. Real-time webhooks suit events like a won deal. Scheduled syncs suit bulk data like a price list. Where a vendor's native connector fits, we use it. Where it does not, we build against the documented API, make each call safe to retry so a timeout cannot create a duplicate order, and log every failure with enough detail to fix it.

We test with the awkward cases: a customer renamed after an order, a deal reopened after invoicing, a credit note. These are the situations where integrations break in the first month, and finding them in testing is far cheaper.