Migrating a customer database starts with a question: what information must the team find in the new CRM on its first working day? A customer list, open deals and communication history serve different purposes. Mixing them in one file can leave sales representatives without the necessary relationships even after a technically successful upload.
This guide helps you prepare a data map, test sample and reconciliation rules before a bulk import into Bitrix24. You can do part of the work yourself in a spreadsheet. All names and numbers in the examples are illustrative; do not use someone else's live database for practice.
What you need before the first import
Prepare four things: an unchanged copy of the source data, a field-mapping table, a list of disputed records and a test-import scenario. Also appoint someone authorised to decide which of two contact versions is correct. A developer can identify discrepancies but should not guess a customer's business history.
If the data exists in several places, do not choose the largest file as the master. It may contain old exports and duplicates. The live CRM may be the current source for phone numbers, the accounting system for company details and a sales representative's spreadsheet for the next contact date. Each type of information can have its own source of truth.
| Data | Example source | Who resolves discrepancies |
|---|---|---|
| Contacts | Active customer spreadsheet | Head of sales |
| Company details | Accounting system export | Person responsible for accounting |
| Open deals | Current order log | Each deal's owner |
Record the date and time of every export. Employees continue working while migration is being prepared: a new phone number or deal may appear after the file was saved. Account for that gap when switching systems.
Separate the contact, company and enquiry
One source row does not always equal one CRM record. “North Company, Anna, installation request” may contain three entities: a company, a contact and a deal. Retain the original identifier for each or assign a technical identifier in the working copy.
Do not replace identifiers with names. Two companies may share a name, and one person may be involved in several orders. A source record's identifier explains where the final record came from even after its name or phone number changes.
Draw a simple relationship: company C-014, contact P-087, deals D-110 and D-111. In the test import, both deals must appear under the correct contact and company. If the records exist separately but their relationships are missing, the migration has not passed acceptance.
Map fields and define empty-value rules
Every source column needs a clear meaning and destination. “Date” is insufficient: it could mean the enquiry date, payment date or next call. Ask the employee who uses the field and record the definition beside its name.
| Source field | Destination field | Rule |
|---|---|---|
| Next call | Next contact date | Clarify ambiguous dates before importing |
| Sales rep: AP | Owner | Map to a specific current employee |
| Status: considering | Agreed stage | The process owner defines the meaning |
| Phone | Contact phone | Retain the source and agree on a consistent format |
An empty cell, zero and “unknown” are not interchangeable. A zero amount may mean a free service, while an empty value may mean no estimate has been prepared. Leave a missing phone number missing. An invented replacement will compromise later matching and the team's work.
Define a separate reassignment rule for employees who have left. Assigning every record to the administrator may seem quick, but it hides the actual distribution of work. Retain the former owner in an agreed history field if the team needs it.
Test transformations on a copy
Create a working file separate from the original. Add “source identifier”, “decision” and “reason for change” columns. Changes must be traceable: a week later, another employee should be able to understand why a row was merged, excluded or flagged for clarification.
- Treat phone numbers and codes with leading zeros as text if numeric formatting changes them.
- Check dates such as 03/04: without an agreed format, the month and day are ambiguous.
- Remove accidental spaces where they interfere with comparison, but preserve the meaning of comments.
- Test line breaks, quotation marks and the CSV delimiter on a short extract.
- After saving the CSV, reopen it and check that Cyrillic text, identifiers and columns remain intact.
CSV is a delimited text file. It does not retain formulas and formatting in the same way as a spreadsheet workbook. Import values; keep calculations and the preparation log in a separate working copy. Do not skip reopening the file: data that looks correct in its original application may import differently.
Resolve duplicates without losing history
Start with possible matches, rather than automatic deletion. An email address may belong to a shared company reception desk, and several employees may use one phone number. For a disputed pair, compare additional attributes and linked deals.
Illustrative example: two rows refer to the same contact, but one contains a supply request and the other a maintenance enquiry. You may merge the contact after checking, while retaining the enquiries separately. Record which source identifiers contributed to the final record.
Classify decisions as “merge under a confirmed rule”, “keep separate” or “review manually”. Put unresolved records in a separate list with an owner. Calling that list “quarantine” does not mean deletion: the data remains available for a decision.
Build a test sample with awkward cases
Include ordinary records and exceptions: a company with several contacts, a contact with two deals, an empty optional field, a long comment, a former employee and a disputed duplicate. Ten perfect rows test only the perfect case.
The official Bitrix24 import instructions explain the CSV template and field mapping. They also state an important limitation: the built-in deal import creates new deals and does not update existing ones. Re-importing the same file must therefore not be treated as safe synchronisation. Check the chosen tool's capabilities before using a live database.
- Download the template for the specific type of record.
- Agree on a test environment and prepare a sample without unnecessary personal data.
- Check the mapping of every column before starting.
- Save the report of accepted and rejected rows.
- Open the created records and check fields, relationships, owners and permissions.
- Before repeating the test, establish what will happen to records already created.
Reconcile counts and meaning
Suppose an illustrative contact file contains 240 rows. After merging 12 confirmed duplicate rows, 228 contacts remain; you decide not to migrate 18 archived contacts yet. The migration scope contains 210 contacts: 202 are imported and eight await clarification. The totals reconcile because every source row has an explainable outcome.
This calculation applies only to contacts. Do not add companies, contacts and deals into one total and compare it with source rows. Also verify relationships and meaning: correct amounts, dates, history and owners. Matching totals will not reveal a contact linked to the wrong company.
A check record should include the source identifier, new CRM identifier, expected value and result. A screenshot saying “import completed” is not sufficient.
Agree on the switch and error response
Set the final export time and appoint someone to account for later changes. For a small migration, a short agreed editing pause may be easiest. If pausing is impossible, you need a separate, tested way to transfer subsequent changes.
Keep the old database available for reading until reconciliation is complete. Record stop conditions: lost relationships, unexplained discrepancies, incorrect permissions or widespread duplicates. Returning to the previous system must account for new records created after launch: restoring an old copy alone could lose them.
The Bitrix24 help centre provides an overview of migrating different data types. One CSV does not transfer every setting and piece of history; check the project scope separately.
When your own preparation is enough
You can prepare a small, understandable spreadsheet with one record type yourself if you have time for a test import and reconciliation. Do not buy a custom integration before checking the built-in import. Complex relationships, regular updates, multiple systems and access restrictions require a separate technical solution.
A field map, anonymised sample, volume and exception list are enough to start a discussion with a provider. Include migration results in implementation acceptance; check data preparation and correction as separate estimate items.
Useful terms
- Field mapping — the rule assigning each source column to its destination.
- Identifier — a stable record number that lets you find it after its name changes.
- Deduplication — finding and resolving duplicate records.
- Reconciliation — checking counts, values and relationships after migration.
- Delta — changes made between two export times.
Apply this to your task
Prepare a field map, exception list and test-migration record with an explainable outcome for every source record.
Bitrix24 migration data map: open the worksheet · Download the CSV to complete. Free access, no registration. Use it yourself or share it with your provider.