CRM migration and cleanup

CRM migration and cleanup is one service with two halves: 80x moves your fund's data between CRMs the way engineers move production databases, and repairs the data when a past migration has already gone wrong.

The system being replaced holds years of relationship history, deal flow, and notes that live nowhere else. Moving that data is the riskiest part of switching CRMs, and it is usually treated as an afterthought: an export, an import wizard, a long weekend. The damage surfaces months later as reports that do not reconcile and history nobody trusts. A careful migration costs days. A careless one costs a year of untrustworthy data, plus the careful migration you end up doing anyway, in reverse.

The migration doctrine

Five phases, in order, none skippable.

1. Map. Before moving a single record, every field in the old system gets a written mapping to a field, type, and conversion rule in the new one, including the fields you deliberately drop. The destination schema is created by script, not by hand, so the setup can be repeated exactly.
2. Dry run. The full import executes with writing switched off, so mapping mistakes show up as lines in a log instead of corrupted records. Every migration script 80x writes defaults to dry run and requires an explicit apply flag to write anything.
3. Idempotent import. Idempotent means running it twice produces the same result as running it once. A migration moving tens of thousands of records over an API will be interrupted, so the import saves checkpoints and keys every record on a stable ID from the old system. It resumes without duplicating. The duplicate catastrophes we get called in to fix are imports without this property, run more than once.
4. Verify. Record counts per object and per pipeline stage, side by side for both systems, with every difference explained in writing. Then a random sample compared field by field, including note text and dates. Counts catch wholesale loss; samples catch mangling.
5. Freeze. At cutover the old system goes read-only. Writing to both systems "temporarily" is how a fund ends up with two wrong databases, because the verification counts stop meaning anything.

Data rescue after a bad migration

When the migration already happened and the workspace is a mess, the work changes shape from moving data to proving what can be safely repaired.

• Deduplication at scale. The tool deletes on its own only where duplication is provable: note text identical character for character, or a copy verified as fully contained in the note being kept, re-fetched and re-checked immediately before deletion. A person reviewing a thousand provably identical pairs adds no judgment, only fatigue.
• Date backfills from status history. Bad imports stamp every record with the migration date, which erases the timeline your funnel metrics are computed from. The true dates often survive in the CRM's own status history, and a backfill can reconstruct them. Backfills write only where a field is empty, so they can never wipe out a value a human set.
• Review queues for ambiguity. The same note appearing on different companies might be duplication, or a legitimate note about a deal involving several parties. Ambiguous cases go to a human review queue, published inside the CRM itself, never onto the delete list. An automation that guesses on ambiguous data is just a hygiene problem on a schedule.

Backup first, rollback always

Every job that deletes or changes data writes a full backup and a log of intended changes before touching anything, and does nothing until you explicitly tell it to apply. Every deletion is logged to an audit file, so the whole operation can be rolled back. The finished-state test is idempotency: re-run the cleanup and it should plan zero further deletions.

What an engagement produces

• The field-mapping document, reviewed with you before anything runs.
• Migration and cleanup scripts in a repository you own, dry-run by default.
• The verification tables: count parity and spot-check results, both sides.
• Full backups and a per-change audit trail.
• A review queue inside your CRM for everything the tooling refused to decide alone.

Proof

After a botched Affinity-to-Attio migration at a fund-of-funds, 80x reduced 4,892 notes to 3,407 in the first live pass: 1,486 deletions, zero errors, full backup and rollback trail. Later passes brought the total to 2,358. Over 1,000 duplicate notes had been dumped on the fund's own company record, 60 ambiguous groups were escalated to a human review queue instead of deleted, and an adversarial second verification correctly rejected 5 false duplicate candidates. Re-running the tool plans zero further deletions. At a European PE platform, 76 date fields across 54 deals were backfilled from the CRM's own status history after the automations stamping them had silently died.