CRM migration CSV builder: check the file before you import it
Most CRM migrations do not fail on the import. They fail six months later, when the pipeline turns out to contain three versions of the same client, half the phone numbers in four formats, and statuses spelled six different ways. Paste your rows here first and find out what you actually have.
Paste the rows, read the report, take the clean file
Paste your export or a selection straight from the spreadsheet — comma or tab separated both work, and the first line should be your column header. The tool identifies which columns are names, phones, emails, companies, statuses, and dates, then reports row by row: what is missing, what is duplicated, what cannot be read, and what it changed. Every automatic change is listed so you can reverse it. Then choose which columns carry over and copy or download the cleaned CSV. Nothing is uploaded — the whole thing runs in your browser.
Comma and tab separated both work, and quoted cells containing a comma are handled. Nothing you paste is uploaded anywhere — the check runs in this page, and the CSV is produced in your browser. The rows shown are a worked example; replace them with your own export.
6 data rows checked. 0 ready, 2 ready with changes, 2 need review, 2 blocked. 12 issues found in total — 2 blocking, 3 to review, 7 changed automatically. Delimiter detected: .
Row-by-row report
| Row | Record | Verdict | What was found |
|---|---|---|---|
| 1 | Rohit Sharma | Ready with changes (1) |
|
| 2 | Priya Nair | Blocked (3) |
|
| 3 | Amit Verma | Ready with changes (2) |
|
| 4 | Sneha Iyer | Check (1) |
|
| 5 | Rakesh Gupta | Blocked (3) |
|
| 6 | Farida Qureshi | Check (2) |
|
Choose what carries over
Copy and download are announced here once you use them.
What this tool cannot do. It has no way of knowing whether a phone number is real, whether a person has consented to be contacted, or whether two records with different names and different numbers are the same person — so it cannot merge duplicates it has no signal for. It also does not understand your business: a status it flags as unrecognised may be perfectly valid for you, and a date it reads as ambiguous is genuinely ambiguous. Every automatic change is listed above as “Changed” so you can reverse it, and a cleaned file is a file that was cleaned by a tool, not a file that was verified.
How this is calculated
Phone normalising = strip non-digits, drop 91 / 0 prefix → 10 national digits
Duplicate phone = same 10 digits already seen on an earlier row
Duplicate email = same lowercased address already seen on an earlier row
Date parse = yyyy-mm-dd, or dd/mm/yyyy, or 12 Mar 2026 → yyyy-mm-dd
Ambiguous date = both numbers ≤ 12 and they differ (03/02 could be either)
Status normalising = match a known variant → canonical stage name
Verdict = Blocked if any error, else Check if any warning,
else Ready with changes if any change, else ReadyDuplicates are only found by normalising first, which is the single most useful thing this check does. A number written as +91 98111 22333, one written as 98111 22333, and one written as 98765-43210 style text are the same ten digits to a person but three different strings to a spreadsheet. Comparing raw strings finds none of them. Dates get the same treatment, read as dd/mm/yyyy because that is the Indian convention — and where both readings are possible the row is flagged as ambiguous rather than guessed, because 03/02/2026 is genuinely two different days and the tool has no way to know which you meant.
Worked example: six rows, twelve problems
The example data is six rows lifted from a plausible spreadsheet. The tool reads the header, detects tab separation, and maps Name, Phone, Email, Company, Status, and Created to the right fields. Row 1, Rohit Sharma, is clean apart from an ambiguous date — 12/01/2026 is read as 12 January and flagged, because both readings are possible. Row 2, Priya Nair, is blocked: her phone number is identical to row 1’s, which is either a duplicate record or two people sharing a number, and only a human can say which. Her status “contacted” is normalised to “Contacted” on the way through.
Row 3, Amit Verma, is where duplicate detection earns its keep. His phone is written as “+91 98111 22333” and row 5, Rakesh Gupta, has the same number written as “98111 22333”. As strings they are different. As ten digits they are identical, so row 5 is blocked and points at row 3. Row 5 also carries the status “proposal sent”, which is normalised to “Proposal”. Row 4, Sneha Iyer, has no email and is marked for review rather than blocked — a record with a phone number is reachable. Row 6, Farida Qureshi, has neither a phone nor a status, so the pipeline stage will have to be set by hand. Across the six rows: 2 ready with changes, 2 to review, 2 blocked, and 12 issues in total — 2 blocking, 3 to review, and 7 changes applied automatically.
What this tool cannot do, stated plainly
It has no way of knowing whether a phone number is real, whether it belongs to the person you think it does, or whether the person has consented to be contacted. A row with a valid-looking number is not a reachable customer. It also cannot detect a duplicate it has no signal for: two records for the same person with different names and different numbers look like two people, and a near-miss surname is not evidence of anything. A row will pass this check and still be a duplicate of a company you already have.
It does not understand your business either. A status it flags as unrecognised may be exactly the right stage for you, and a date it calls ambiguous really is ambiguous. Every automatic change appears in the report as “Changed” so you can reverse it, because a file that was cleaned by a tool is not the same as a file that was verified. Treat the output as a review queue, not a finished import.
The reason this matters is that migration damage is usually done by a conversion nobody looked at. Deciding how a company, a contact, and a lead relate to each other — and what your merge policy is — is setup work, not an import setting, and the same company often arrives once as a lead, once as a company, and once as a contact with a slightly different name. In NoxOrigin, importing from an existing spreadsheet or CRM is scoped work rather than a self-serve promise, precisely because the mapping is the project. If you want that done properly, read how the customer record is structured, and the migration reasoning in CRM vs WhatsApp and spreadsheets and moving from Excel to software. For the commercial argument, see CRM vs spreadsheets.
Related tools
- Quote Estimator Calculator — check what the migrated work is worth before you quote it.
- Agency Utilisation Calculator — check whether the roster can deliver it.
- Lead Follow-Up Planner — give every imported lead a dated next action.
- Lead Response Time Calculator — how much of the month is spent waiting for a first reply.
- Lead management software — the same record once the rows are clean.
- Platform & Control — permissions, imports, and exports.
- All free tools for small business operations.
Want the record to stay clean after the import?
The import is the easy part. What decides whether a customer record is still findable in two years is everything after it: companies and contacts held once, with an activity timeline, custom fields, and files; opportunities carrying an owner, a stage, and a dated next action rather than knowledge in one person’s head; and a won opportunity becoming a project without the client being re-typed. Ownership, stage, and next action being fields on the record is also the single most common reason CRM data stops rotting — when the owner leaves, the rest of the team can still see exactly where every deal stood.
Permissions are evaluated per action, so operations and finance can read the client record without being able to rewrite the pipeline. And a cleaned file is only the beginning: a reviewed migration, an agreed merge policy, and a record that the project, the quote, and the invoice can all attach to are what make the difference six months later.