Moving Data from Excel to a CRM Without Losing Any

The file is called "clients_current_final2_rev.xlsx", it has 4,800 rows and 31 columns of which twelve are populated, plus three sheets nobody remembers the purpose of. That is usually exactly what the customer database of a seven-year-old company looks like. You cannot move it into a CRM with one button, but there is no tragedy here either — you just need an order of operations.

Audit first, import second

The main mistake is loading it as-is with the intention of "sorting it out later". Later never comes: the junk dissolves into the system, and within a month it is impossible to tell a real customer from a row created by a typo. Before importing, the file needs to be counted: how many unique phone numbers, how many records with no contact details at all, how many duplicates by name, what share of rows has data in the wrong columns. On a 5,000-row database this audit takes a day and saves weeks.

Typical spreadsheet problems

• Duplicates: one customer entered three times with different spellings of the name and one phone number. The merge key is almost always the number, not the name.
• Free-form phone numbers: +7, 8, brackets, hyphens, two numbers in one cell, an extension after a comma. All of this is normalised by a script, not by hand.
• Dates: 05.03.26, 2026-03-05, "5 March" and "spring". The last one cannot be saved; the rest can be normalised.
• Meaning buried in notes: "10 percent discount, call after 6, husband Igor" — one cell, three separate fields in the future record.
• Dead records: customers who have not been in touch for five years. They are not deleted but flagged, so they do not skew the statistics or receive mailings.

The order of work

Step one — make an untouchable copy of the original and work only with the copy. Step two — flatten the table: one row equals one customer, no merged cells and no headers halfway down the sheet. Step three — map the columns to CRM fields and decide where to put anything with no counterpart: usually a single text field called "note from the old database" is created, which is more honest than losing the information. Step four — a test import of 50 rows. That is where encoding, delimiters and stray whitespace show up. Step five — the full import and a reconciliation of control totals: record count, unique phone count, deal totals. If the figures before and after do not match, investigate immediately.

What to do with deal history

Often the spreadsheet holds not just a customer list but a purchase history too. That is worth migrating as well — without it the CRM will not show repeat sales or calculate LTV, and that is half the point of the system. Technically it is a separate import linked by customer identifier, and it should be done after the customer list has been loaded and cleaned. We normally budget 20–40 hours for migrating a database of this size, including the normalisation scripts; it is part of a CRM rollout project.

The legal side

A customer database is personal data, and from the moment you load it into a system you become its operator with all the obligations under 152-FZ: storage on servers in Russia, restricted access, deletion on the data subject's request. This is also a good moment to strip out what you do not need: keeping five-year-old passport details is both risky and pointless. What exactly to check in the new system before launch is set out in our section on data protection.

After the move

Do not delete the old file for at least three months, but make it read-only — otherwise somebody will carry on maintaining it in parallel and you will end up with two diverging databases. Two weeks after the import it is worth manually checking 30 random records: a cheap spot check that catches systematic mapping errors. And agree in advance who is now responsible for data quality — without an owner the database degrades back within a year, whether it lives in a spreadsheet or a system. If there is nobody with the time to do the migration, we can handle it on our side along with the configuration.