What to migrate when you switch CRM, and what to leave

Three things move to a new CRM: clients, deals and the work history attached to them. What stays behind is the automation setup, the fields nobody ever filled in, and records the company does not actually use. Sorting the two piles is a job for the weeks before a switchover date is fixed, because the size of the base drives both the timeline and how willingly the sales team opens the new portal.

What moves without discussion

Contacts and companies with phone numbers, email, addresses and tax details. Open deals with their stage, amount and currency. Closed deals for the period still used in reporting, usually two or three years back, beyond which the numbers are of historical interest only. The owner and the creation date travel with the deal, otherwise reports on earlier periods cannot be rebuilt in the new system at all.

What gets cleaned before the import, not after

Duplicates first. In a spreadsheet one client lives in three rows spelled three ways, and in the old CRM the same client exists twice because he called from two numbers. Merging them is far easier while they are still rows in an export than later in the portal, where every record already has tasks and activities hanging off it. Phone numbers are normalised to international format with a country code in the same pass: without it telephony, search by number and the matching of an inbound message to a record all fail quietly.

The second clean up is fields. Before migrating, it pays to count how many records actually have each field filled. A field present in two percent of records is nearly always the residue of a process cancelled a year ago, and there is no reason to carry it into the new portal.

What stays in the old system

Automation. Pipelines, bots, campaign sequences and spreadsheet formulas are built differently in every system, there is nothing to export them into, and they are rebuilt with the tools of the new portal. That is not a loss: halfway through it usually turns out that half the old rules existed to work around limitations of the previous CRM. Data kept without a clear basis is a separate question. Personal data in the UAE is governed by Federal Decree Law No. 45 of 2021, which makes a migration a good moment to leave a ten year old subscriber list behind with the old system rather than carry it over.

Why history takes longer than contacts

Contacts and deals go into the portal as a file, while messages, calls and attachments have to be moved through the REST API, one record per call. The Bitrix24 limits are published and can be planned around: up to 50 methods in a single batch request, a request counter that on most plans decreases by two per second and blocks at 50, which at a steady pace allows roughly 172,800 calls a day, and a hard 60 second ceiling on each request. A base of several tens of thousands of deals with full history is therefore a job measured in hours, and it is scheduled separately from cutting over telephony and web forms.

What the built in import cannot do

The built in importer takes a CSV file and creates leads, deals, contacts and companies, while invoices, estimates and smart process items are loaded from the list view. There are three constraints. Import only creates deals, it cannot update existing ones, so a second pass over the same file goes through duplicate control with replacement. A deal with several products is described by several rows sharing one identifier. And only an administrator, or a user granted the right, can start an import at all. Anything beyond that is done with an application or through the API.