Move your referral spreadsheet into a system without losing history

Every guide to CRM data migration covers the same ground: export the sheet, clean the columns, map the fields, import. All of it is right and none of it mentions the thing a referral spreadsheet is actually for. Follow a generic migration guide and your contacts arrive fine while your referral history quietly degrades into trivia.

Here is what a naive migration loses, the signs your spreadsheet is already costing you, and the afternoon plan that keeps everything.

Five signs the spreadsheet is dying

You do not wake up one morning and decide to migrate. You notice symptoms:

1. Reconciliation takes longer than the referrals are worth. You spend Friday afternoon matching payments to rows, scrolling for names, and wondering whether last month's statement was right. The spreadsheet is not saving time anymore; it is consuming it.
2. Two people edited the same row. You see a fee status that says "paid" when you know it has not been, or a deal amount that changed without a note. Parallel edits are invisible in a sheet without audit logging.
3. A partner asked a question you could not answer quickly. "How many referrals have I sent this year?" should be a filter, not a twenty-minute project.
4. You lost track of what you owe. The paid-to-date column drifted from reality somewhere around month four, and reconstructing it means reading old bank statements.
5. Someone said "just add another column" and you flinched. The sheet is a load-bearing wall. Every new column risks breaking the formulas, the filters, and the one person who understands the layout.

If three of these are true, the sheet has graduated from tool to liability. The move is overdue.

What generic migrations destroy

Three kinds of referral data do not survive a standard contacts-and-deals import:

The introducer becomes a string. Your sheet has a "Referred by" column with "Sarah Chen" in it. Imported as a text field, that is a label, not a link: rename Sarah, merge her duplicate record, or try to count her referrals, and the connection is gone. The introducer must arrive as a linked record, an association to a real contact. This is the single most common mistake, and every partner report you run afterward inherits the damage.

The dates flatten. The introduction date is what settles two-partner disputes and defines your attribution window. Naive imports either drop it or overwrite it with the import date, which turns every deal into "referred the day we migrated." One disputed referral later, you discover the evidence you needed was the evidence the import silently erased.

Payables history resets. The columns you are most scared to lose: fee agreed, fee status, paid to date, still owed. None of them map to a default CRM field, so they silently do not come along, and next month's partner statement starts from a blank ledger. Partners who were owed money before the migration are now owed money that the system cannot prove.

Decide the destination first

Three honest paths, and the sheet you have today works with all of them:

• Your CRM, upgraded. Build the referral fields before importing anything: the CRM referral field kit lists the exact properties, association labels, and stages for HubSpot, Salesforce, or any CRM. Import into the structure, not before it exists.
• A referral layer. A system that models introductions natively, where the introducer, the date, and the fee ledger are first-class. This is what Introzy is; the import maps your columns to the model directly.
• The improved spreadsheet. Legitimate below a dozen active referrals: our tracking template implements the correct columns for free. Migrate to it in ten minutes and revisit this post when reconciliation starts eating your Fridays.

The wrong destination is the one you pick under pressure. Decide before you export.

The column mapping

If your sheet has columns not on this list, they fall into two categories: data that matters (partner tier, agreement link, payout method) which you add as custom fields before importing, and data that does not (highlight colors, sort-order hacks, scratch notes to yourself) which you leave behind.

Five mistakes people make during the migration

1. Importing before building the structure. If the fields, labels, and pipeline stages do not exist yet, the import has nowhere to put the referral-specific data. It either drops silently or lands in a catch-all text field you will never clean up.
2. Cleaning the data to perfection. One pass for duplicates and inconsistent names. Two passes to catch what the first missed. Three passes and it is next quarter. Perfect is how an afternoon becomes a project. Import clean enough, then fix the five records that matter by hand.
3. Running live during the cutover. Both the sheet and the system are accepting edits for a week while you "transition gradually." You now have two sources of truth and zero confidence in either. Freeze the sheet, import, switch. One afternoon.
4. Forgetting the payables. You migrate contacts and deals, call it done, and discover on payout day that the system thinks every partner starts at zero. Payables history is part of the migration, not a follow-up task.
5. Not telling your partners. Your partners do not care about your CRM migration. They care that their referral count, their balance, and their next payment are correct. A one-line note ("we upgraded our tracking; your history is preserved, reach out if anything looks off") costs nothing and prevents the worst conversation.

The afternoon cutover

1. Freeze the sheet. Announce it, mark it read-only, no edits after the export. Parallel edits during migration are how records vanish without anyone lying.
2. Export and clean. One pass for duplicate introducers and inconsistent names. Do not perfect it; perfect is how afternoon becomes quarter.
3. Create the structure first. Fields, labels, stages, per the field kit. Importing into structure is mapping; importing before structure is retyping.
4. Import in dependency order. Contacts and companies, then deals, then the referral links and money fields. The introducer association needs both ends to exist.
5. Verify with three questions. Pick one partner: does their referral count match the sheet? Pick one deal: does the introduction date match? Pick one payable: does the owed amount match? Three matches and the migration is trustworthy; any miss and you have found the broken mapping while it is still one afternoon old.
6. Send the note. One line to active partners: history preserved, nothing changes on their end, reach out if anything looks off.
7. Park the sheet, read-only, forever. It is the audit trail of the era before the system. Deleting it buys nothing.

What changes the day after

The spreadsheet answered questions reluctantly: scroll, filter, hope the formula still works. The system you migrated into answers them instantly, or it was the wrong destination.

• Partner asks "how many referrals did I send this year?" Filter, not a project.
• Finance asks "what do we owe across all partners this quarter?" A report, not a reconciliation.
• A deal closes and the partner needs to know. A notification or a portal update, not a manual email you might forget.
• Two partners claim the same deal. The introduction dates are real dates on real records, not a column someone might have edited.

The move is not about the technology. It is about making the next referral land in a system that can answer the question the last referral raised.

We wrote about the engineering side of making step 4 forgiving in rethinking CSV imports: the import flow is built to activate your data, not just accept it.

The whole point of the move is that the next referral arrives into a system that does the work the sheet could not. If the destination you pick is Introzy, start free and bring the sheet with you: the import maps the columns above directly, introducer links and payables included.

Stop reading about referrals. Start tracking them.

Free up to 5 referrals a month. Every feature included. No card to start.