CRM Rebuild & Migration, with the Automations on Top

You cannot automate on top of a data model that does not exist.

The CRM is a spreadsheet, or three. Or it is a HubSpot nobody configured, and the real state of every deal is in one person’s inbox. Every automation proposal dies there.

Every node with its icon, as on the n8n canvasstarts a runHover a node for its name and type

• 01Source Profiler & Audit

  13 nodes · 14 connections · 5 notes

  fill rates, distinct values, duplicate clusters

• 02Dedupe + Mapping Engine

  19 nodes · 21 connections · 5 notes

  normalise, score, merge, map, stage

• 03Migrate (Dry Run + Live)

  17 nodes · 17 connections · 4 notes

  validate, then diff or write, with a rollback log

• 04Rollback Executor

  12 nodes · 13 connections · 3 notes

  a confirmed undo; the unresolved go to a person

• 05Routing + Stage Follow-Up

  19 nodes · 19 connections · 3 notes

  intake, grading, the 3/5/7/14/21/30 ladder

The gates, 9 If and Switch nodes, decide whether anything happens next: a countable part of the system, not a claim about it. The 20 sticky notes carry the reasoning on the canvas, at the point it applies.

HoverTap a card to read what it prevents.

• The dry run is the default

  The dry run is the default

  Forgetting to switch it off wastes a run; forgetting to switch it on writes thousands of records into a live CRM. Every write sits past that one branch.

• The dry run shows the payload, not a count

  The dry run shows the payload, not a count

  “1,842 contacts would be created” proves nothing. The exact JSON, and the fields left empty, is where a bad mapping shows.

• Reserve, create, confirm

  Reserve, create, confirm

  A crash midway leaves a known unknown a person can resolve, instead of an orphan record nothing knows about.

• Rollback asks for the run by ID

  Rollback asks for the run by ID

  Not a checkbox: the thing typed is the thing destroyed, so the wrong run cannot be confirmed from muscle memory.

• Intake normalises exactly like the migration

  Intake normalises exactly like the migration

  Otherwise new leads start recreating the duplicates the migration just spent a week removing.

• Suppression lives in the same query

  Suppression lives in the same query

  Whether someone has replied is part of the same SQL condition that decides what is due, so no later step can reorder or forget it.

• Built, not yet deployed. Every file imports cleanly; there has been no successful run against a live HubSpot portal.
• The destination is HubSpot. GoHighLevel or Pipedrive means rewriting the migration, the rollback and the create step.
• Contact-to-deal associations are not created yet. On a real engagement that is a further workflow.
• Rollback deletes what the migration created. It does not restore records changed in place — and the migration changes none.