A customer database in Excel has one unpleasant property: it works exactly as long as only one person works with it. After that you get a file called “Database_current_v3_FINAL”, every salesperson keeps a private list on their phone, the same TOO (an LLP, the standard Kazakhstani limited-liability company) lives in three rows with three different phone numbers, and the “Customer” column mixes personal names, legal entity names and notes like “call after lunch”. The file has no revision history, no access permissions, no link between a company and its contact person and no reminders — which is exactly why people move off it. The decision is usually made not out of love for automation, but after the same customer gets called twice in one week by two different salespeople.
What follows is what a move to Bitrix24 looks like from the inside: what actually transfers and what stays in the old file forever; how to prepare the spreadsheet so the import doesn’t turn phone numbers into scientific notation and a twelve-digit BIN (the business identification number every Kazakhstani legal entity has) into an eleven-digit one; in what order to load companies, contacts and deals so that they end up linked to each other; and what to check after the upload. The main point up front: Bitrix24 has no built-in “undo import” button, so all of your insurance is put in place before you click the button, not after.
What moves to Bitrix24 and what stays in Excel forever
- Fields move. Company name, personal name, phone numbers, emails, city, segment, deal amount and stage, the assigned owner, custom fields — everything that physically sits in a cell.
- Requisites move. BIN and IIN, bank details and addresses are loaded from the same file, but through a separate mechanism — with the requisites import option enabled and a set of service columns.
- Communication history does not move. The import creates a record with fields, but it does not create a timeline: there will be no calls, emails, chats, comments or activities in it. The built-in export-import doesn’t carry history between two Bitrix24 portals either — for that, the Market has dedicated migration apps (the “Import, export” category), and some of them can move comments, mentions and activities. From Excel the history won’t arrive under any circumstances: it simply isn’t there.
- Files and message threads do not move. Contracts in a folder on a drive and WhatsApp conversations stay where they are. At best, put a short text summary into a comment or a custom field called “History before the move”.
- Dates do not arrive the way they look in the file. One case is documented officially: for deals, the closing date is replaced with the upload date, and the workaround from that same help article is to import the real date into a custom field and copy it into the system field with an automation rule. Don’t guess about the other dates: run a five-row pilot and see exactly what lands in the record. Only a REST import is guaranteed to preserve the original creation dates and authors.
Where to load the data: leads, contacts, companies or deals
The most expensive mistake is made before the file is even opened: most often the entire database is dumped in as leads, and the next morning the sales team gets thousands of unprocessed enquiries, a red counter and no way to work at all. If the difference between a lead, a contact and a deal still sounds abstract, look into the glossary, and build your pipeline and its stages before the import — how to set one up from scratch. A stage that doesn’t exist in the portal will not appear out of the file.
- A lead is an unprocessed inbound enquiry, not an existing customer. You don’t load an entire database in as leads.
- Companies — TOOs and IEs together with their requisites: BIN, address, bank details.
- Contacts — private individuals and the contact people at companies. With retail customers from Kaspi, decide in advance whether you need them in the CRM at all: if the store is later connected to the portal through the Kaspi integration, orders will start arriving on their own, and that same retail base loaded from Excel will give you a second set of records.
- Deals — only for real, live negotiations. A just-in-case deal for every customer turns the pipeline into a landfill, and from then on your conversion rate is calculated on garbage.
Four ways to migrate: CSV, a Market app, the REST API and 1C exchange
The built-in import covers most small and mid-sized business needs, and that’s where you should start. Market apps are worth a look when the move is a standard one — from a well-known CRM (there’s a separate walkthrough of migrating from amoCRM for that scenario) or from portal to portal. If what you have is XLSX, the rule of thumb is simple: the free “Import from Excel” app accepts XLS and XLSX without re-saving and can build a linked company, contact and deal out of a single row — something the built-in import fundamentally cannot do. In exchange, you hand a third-party app access to your entire database and accept its field-mapping logic, so the first run is done on a test batch of twenty rows, exactly as with CSV. REST is what you need when there is a lot of data, the relationships are complex, or it matters that real creation dates and authors are preserved: the import methods have createdTime and createdBy parameters, and they don’t trigger automation rules or business processes.
| Method | When it fits | Limitation |
|---|---|---|
| Built-in CSV import | A flat table: companies, contacts, requisites, simple deals. The portal administrator can do it in an evening | CSV only; the import is designed to create new items — you cannot mass-update existing records from a file, and the only record it can change is one the import recognises as a duplicate, and only in the way set in the duplicate control block; every record is dated the day of the upload, and there is no rollback button |
| A Market app | A standard scenario: migration from a specific CRM or between two portals; XLS and XLSX without conversion; a linked company, contact and deal from a single row | Someone else’s field-mapping logic, third-party access to your whole database, behaviour that has to be verified with a trial run |
| REST API (import methods) | Large volumes, complex relationships, preserving real dates and authors (createdTime, createdBy), repeat runs in which the script itself decides what to create and what to update | You need a developer and a key with broad permissions; the import methods only create items, updating is a separate method, otherwise a repeat run breeds duplicates; the batch import accepts up to 20 items per request and requires them in ascending order of creation date; a bug in the script propagates across the whole database instantly |
| 1C exchange | The database actually lives in 1C, and the Excel file is just an export of it | This is no longer an import but a project of its own: in Kazakhstani configurations the mapping almost always needs custom work |
How the built-in CSV import works
The button lives in the section settings. For contacts that’s CRM, Clients, Contacts, the gear icon, “Import from CSV with custom settings”. For companies the item is called “Import company” (in some portal versions, “Import companies”), for deals it’s “Import deals”, and leads work the same way; check the exact wording in the gear menu of your own portal, because it has changed from version to version. Invoices, quotes and smart processes can only be imported in “List” view mode — in Kanban there is simply no import item. If you can’t see the item, there are two possible reasons. The first is permissions: importing can be done by an administrator or by an employee whose CRM access role has been granted the import permission. The second is your plan: the CRM permission role model itself isn’t available on every plan, the basic manager role has neither import, nor export, nor delete, and export — a handy way to grab a sample file — isn’t available everywhere either. Before you go hunting for a bug, check the description of your plan.
On the import page you first set the file parameters: “Data file encoding” (auto-detect by default; if the preview shows garbled characters, set UTF-8 or Windows-1251), “Column separator” (comma, semicolon or colon — the character has to match what is actually in the file) and the “Use the first row of the file for field names” checkbox. Then the mapping step opens: CRM record fields on the left, file columns on the right. Auto-mapping works by matching names; anything unmapped is fixed by hand. The practical conclusion: don’t invent your own column structure — download the import template straight from your own portal’s page, because it will contain the exact field names of your record, including the custom fields you have already created. The second way to get a reference file is to create one record by hand, fill in every field you need, and export the section to CSV.
Preparing the file: where Excel quietly corrupts your data
Almost all of the pain of a real migration is in preparing the file, not in the import itself. And it isn’t Bitrix24 that corrupts the data — it’s Excel, silently, at the moment you save. Work on a copy: don’t touch the “as received” sheet at all, keep a sheet with service columns next to it, and a separate “for import” sheet — only the columns you need, values only, exactly one header row.
- Encoding and separator. The ordinary “CSV (comma delimited)” option in a Russian locale writes the file in Windows-1251 with semicolons inside it, and Cyrillic turns into garbage if a different encoding is selected in the wizard. There are three fixes: pick the right encoding at the import step; save from Excel itself as “CSV UTF-8 (comma delimited)” — a separate entry in the format list since Excel 2016; or re-save the file as UTF-8 in Notepad++ or VS Code (an export from Google Sheets works too). Open the finished CSV in a text editor and look at what the separator actually is — it takes ten seconds.
- Phone numbers. A leading plus in a cell is read by Excel as a formula and swallowed, a long number turns into 7.70113E+10, and the leading zero of a landline number gets cut off. Convert the phone column to text format BEFORE pasting the data and normalise it with a formula, not by eye. Anything that doesn’t parse automatically goes into a “check this” column rather than being guessed at.
- BIN, IIN and other identifiers. Text format only. The first two digits of a BIN are the year the legal entity was registered; for an IIN (the individual identification number of a private person) they are the person’s year of birth, so everyone registered or born in 2000–2009 has an identifier starting with a zero (for those born from 2010 onwards the first digit is a one). Excel strips that zero irreversibly, and a twelve-digit BIN becomes an eleven-digit one. The integrity check is simple — string length: a BIN and an IIN are exactly twelve characters.
- Amounts and currency. Excel thousands separators (1 250 000, including the non-breaking space) go into the CSV as they are and break the amount field — leave a clean number. Put the currency in a separate column: on Kazakhstani portals the portal currency has to be KZT, otherwise deals will quietly arrive in the default currency and your revenue report will be wrong.
- Dates. What ends up in the CSV is what you see on screen, so a short format leaves with a two-digit year, and a “date” typed with an extra space turns out to be text. Normalise the column with a separate formula and paste it as values.
- Table geometry. Merged cells keep the value only in the first row of the block, hidden and filtered rows still end up in the CSV, and only the active sheet is saved into the CSV. Add to that multi-level headers, “Total” rows and subheading separators — the importer expects one header row and uniform data after it.
- Invisible junk. Non-breaking spaces from copy-paste are not removed by TRIM, and they are the single most common reason an obvious duplicate can’t be found. Line breaks inside a cell (Alt+Enter) are a separate CSV killer: one record easily turns into several broken rows. They usually hide in the “Address” and “Comment” columns.
- Formulas and errors. Before the export, copy all the content and paste it as values, otherwise “#N/A” and “#VALUE!” will land in your records instead of data, and the file will still depend on workbooks you no longer have.
- Duplicates inside the file itself. You have to look for them not by company name but by normalised keys: digits of the phone number only, email in lower case, BIN as text, name stripped of the legal form and the quotation marks. The order of reliability is phone, email, BIN, and only as a last resort the name. The master record in a group should not be the first row you come across but the fullest and most recent one, and everything unique from the rest is collected into a comment. And don’t delete duplicates from the source file — flag them: six months from now someone will definitely ask where those records went.
Kazakhstan specifics: BIN, TOO and IE, +7 7XX phone numbers, Kazakh names
Phone numbers in a Kazakhstani database almost always exist in five or six spellings at once: 8 701, +7 701, 87172, 7 (727), a number with an extension and a number with “accounting” typed next to it. Exactly how Bitrix24 compares such numbers when it searches for duplicates isn’t described in the documentation: the portal normalises some formats itself and others not, and the result depends on the portal’s country and on how the number was written. You can’t rely on it — bring numbers to a single +7 7XX XXX XX XX format while you are still in Excel. It also determines whether your telephony or WhatsApp will attach an incoming call to the right record.
- Legal entity names. TOO “Romashka”, Romashka TOO, too romashka and a version without quotation marks turn up in the same column all the time, and sometimes a Latin letter is sitting inside a word, visually indistinguishable from its Cyrillic twin. Bring them to one form: legal form first, one type of quotation mark, no Latin characters.
- Personal names. A single cell can hold a job title, initials and two people at once. Kazakh names are spelled sometimes as Мұхтар and sometimes as Мухтар, and Nurlan Serikuly is a given name plus a patronymic, not a surname.
- The safety column. Parse such rows with a formula, but keep a “name exactly as it was in the file” column and load it into a comment — it is your only protection against a bad parse.
BIN and IIN in Bitrix24 don’t live in a basic company field but in the requisites — and that is fundamental: without requisites a record is useless for an invoice or a contract. The requisites template for Kazakhstan is chosen in the record itself, in the “Requisites” field, and the list of available templates is configured under CRM, More, Settings, CRM settings, Requisite templates. In the file, requisites have their own service columns holding the IDs of the requisite, the template and the country, and the address has to be split into separate columns: street, office, city, region, postal code. Don’t copy specific ID values out of someone else’s article — create one company with Kazakhstani requisites by hand, export the section to CSV and see which numbers you have. Check separately which set of fields your portal uses to search for duplicates: the basic set is name, phone and email, but in some versions and templates the search can also cover requisite fields. If requisite fields aren’t on the list, you will have to catch duplicate legal entities by BIN yourself — by exporting the section and reconciling it in a spreadsheet. And if customers are created in 1C and invoiced there as well, a one-off import treats the symptom: the two databases will diverge within a month, and the right route is 1C exchange, loading from Excel only the part that isn’t in 1C.
A twenty-row pilot and a batch tag
The first run is done on twenty rows, and you should pick the hardest ones: a company with two phone numbers, a name in Kazakh spelling, a BIN with a leading zero, a long name in quotation marks, an IE instead of a TOO, a number with an extension, a comment with a line break inside it. Then you open the records and check every field with your own eyes. If even one entry lands wrong, a proportional share of the whole database will land wrong. Before the live upload, add a batch tag to the file — fill in one value for the entire batch in the source field or a service field, something along the lines of “import of such-and-such date”: that is your only way to later find everything this run loaded with a single filter. Cut large files into chunks of one to two thousand rows, each with its own tag; check the current import limits in the Bitrix24 help at bitrix24.kz, and in practice a fat file has a habit of falling over — and hunting for the error in a five-hundred-row chunk is noticeably more pleasant than in a file of several thousand.
Duplicates and acceptance: what to check after the upload
The import itself has a duplicate control block: allow, replace, merge, skip. For a first upload into a clean portal you normally set “skip” and then work through the list of skipped rows; for follow-up uploads, “merge”: it fills in empty fields only and doesn’t touch what your salespeople have already entered. “Replace” is never clicked blind.
After the import, turn on permanent duplicate control in the section settings and go through the merge list by hand. Automatic merging only fires when absolutely all fields of the records and the assigned owner match, and on a live database that condition is almost never met. Merging can be done by an administrator or by an employee with edit and delete permissions. Secondary records are deleted during the merge and go to the CRM recycle bin, but you can’t treat that as an undo button: items are kept there for a limited time, restoration isn’t available on every plan, and a regular employee only sees in the recycle bin what they deleted themselves. And the most important part — restoring a record from the recycle bin does not undo the merge itself: whatever has already been copied into the master record stays there. So questionable pairs are dealt with by hand, not on the principle of “merge it, we can always restore it”.
- Arithmetic. Rows in the file minus the header minus the empty ones equals the number of records under the batch filter. Count companies, contacts and deals separately. A discrepancy is almost never accidental: it is either duplicate filtering or validation errors.
- Twenty random records by hand. The phone number is clickable and in +7 7XX format; the email is in the email field, not in a comment; the BIN is in the requisites, not in the name; the deal amount is a number and in tenge, not in the default currency; the owner is a real salesperson, not the administrator; the company is linked to the contact, and the deal has a client filled in.
- Dropdown fields. A common silent error: a list field arrives empty because the text of the option was passed instead of the option itself. Check at least one such field on each entity.
- Assigned owners. Employees are added to the portal BEFORE the import, and the file keeps one single spelling of each name. If the whole database lands on whoever ran the import, visibility permissions, per-salesperson reports and call routing all stop working. It is easier to load everything onto one person and then redistribute with a bulk edit than to fix it a month later.
- Segments and tags. City, customer type (TOO, IE, private individual), industry, status — active, dormant, do not call — and source. This has to be marked up as a column in the file: nobody is going to do it by hand across the whole database afterwards.
- Permissions and personal data. Right after the move, close off the export and import permissions in the CRM roles, otherwise the very first salesperson who quits will walk off with the database using that same button, and set “own records only” visibility for rank-and-file staff. While you’re at it, decide on what legal basis you store the personal data of private individuals: by migrating the database you become a personal data operator under Kazakhstani law.
- The source file. A copy with the date in its name goes into the archive, read-only and with restricted access, and from that moment on edits are made in the CRM, not in the spreadsheet. That is your migration backup.
Life after the import: the date Excel gets switched off
The import ends not when the data has been uploaded, but when the old file has stopped existing as a working tool. That is a management decision with a date on it: a day is set, edit rights on the shared file are revoked, the rule “no record in the CRM means no deal” is announced, and the manager stops accepting reports in any form other than reports from the system. A parallel database survives exactly as long as at least one report is accepted in Excel. In parallel, connect your communication channels so the new history starts accumulating inside the records: WhatsApp through Wazzup is the fastest way to show salespeople why they should open the CRM at all. If it turns out the database has moved but the process was never described, start with choosing and configuring a CRM around your actual needs. After that comes the part that costs more than any import — getting the team used to working in the CRM.
