Rescue · Spreadsheets → CRM
The import ran. The result is not usable.
Partly loaded, partly not, and no reliable account of which is which.
We establish what actually transferred, what did not, and what is still recoverable from the source — then quote a fixed recovery scope against that evidence rather than against a guess.
- Profiled first
- Rules agreed up front
- Every change logged
- Counts reconciled
Price cue, ex GST
Assessment from $750
Check what is recoverable Or call 1300 652 280A written finding on what transferred, what is missing, what is recoverable and what it will take. Yours to keep, whether or not you engage us for the recovery.
- Australian managed
- Delivered remotely
- Source data never deleted
- Verification report at sign-off
What goes wrong on this route
The import ran and now there are three of everyone, because the sheet had three copies too
Company names came in as free text, so the same client exists as four separate organisations
Everything landed as a contact and no companies or deals were created at all
Dates imported as text, so nothing can be filtered, sorted or reported on
The notes column was truncated, or arrived as one unreadable block on every record
Nobody can say which records came from which version of the spreadsheet
Why re-running the import usually makes it worse
A second pass against the same rules produces the same result on top of the first one. These are the things that have to be settled before anything is loaded again.
- One matching rule agreed before anything is imported — usually email, sometimes email plus company, never name alone
- Company names normalised, so Pty Ltd, P/L and trailing whitespace stop creating separate organisations
- Phone numbers and addresses standardised to one format, which is what makes the CRM's own deduplication work afterwards
- One row per contact separated from one row per deal, since spreadsheets almost always conflate the two
- Free-text columns read and mapped to real fields or to notes deliberately, rather than by column order
- Quotes, contracts and attachments referenced by the sheet located and linked, since these usually live somewhere else entirely
- Every competing copy of the sheet identified, and one nominated in writing as the source of record
The proof you keep
You will know exactly what came back, class by class.
Recovery is reconciled against the original source, not against the half-loaded destination. That is the only comparison that tells you whether anything is genuinely gone.
Migration Verification Report
Spreadsheet to CRM recovery · Example format
| Record class | Sheet rows | Cleaned records | Imported | Status |
|---|---|---|---|---|
| Contact rows | 8,412 | 6,208 | 6,208 | 2,204 merged by agreed rule |
| Companies derived from contacts | — | 1,944 | 1,944 | Verified |
| Deal rows | 3,118 | 3,118 | 3,118 | Verified |
| Notes held in free-text columns | 11,882 | 11,882 | 11,882 | Verified |
| Attachments found outside the sheet | 2,406 | 2,406 | 2,398 | 8 Accepted Exception |
| Rows with no usable identifier | 187 | 187 | 187 | Itemised, none discarded |
Accepted exceptions are itemised individually with a reason, never summarised as a total. Anything genuinely unrecoverable is recorded as unrecoverable.
Free · About three minutes · No sales call required
Tell us what happened. We will tell you what is recoverable.
The route is already filled in. Four steps, and an engineer reviews every answer — a failed import never receives an automated number, it receives an assessment.
Questions we get on this route
We could just use the CRM's own import tool. Why pay for this?
Often you should, and we will tell you so. One clean sheet, a few hundred rows, one row per contact and no attachments — the built-in importer will handle it. This route is for the other case: several competing sheets, years of history, deals and contacts mixed in the same rows, notes in free text and attachments living somewhere else. The importer will load all of that quite happily, and you will spend the next year working around the result.
Why do the numbers go down?
Because a spreadsheet holds duplicates and a CRM should not. The reconciliation shows three columns rather than two for exactly that reason: rows in the sheet, records after the merge rules you approved, records imported. Nothing is discarded silently. Every row is either imported, merged under a rule you agreed, or itemised as an exception for you to decide on.
There are four versions of the sheet and people still email each other new ones.
That is the normal starting position, and it is most of the reason this is worth doing properly. Part of the work is establishing which copy is authoritative, reconciling the others against it, and identifying what exists only in the outliers. Importing the wrong copy is the failure mode, and it is not recoverable without doing the whole thing again.