- Contacts, notes, tags, and deal history map over. Bespoke custom fields are where it gets interesting.
- Duplicates get merged, not multiplied — and the merge is reviewable.
- Anything that cannot be mapped is listed for review rather than dropped quietly.
Nobody enjoys this part. The reason CRM migrations have a reputation is not the data volume — it is that every team has five years of private convention encoded in tag names, and no export format has ever known what those mean.
01What maps cleanly
- Contacts, with phone numbers and emails normalised to a single format.
- Notes and activity history, attached to the contact rather than flattened into one blob.
- Tags, kept as tags — we do not silently reinterpret them as stages.
- Deal history, where the source has a concept of one.
- Per-channel consent, where the source recorded it. Where it did not, the contact arrives as targetable, not callable.
02Duplicates, and the 0 that matters
Every real database has the same person three times: once from a portal, once from an open house sign-in sheet, once from somebody's phone. Merging them is the point of the import — but a merge that loses a note is worse than a duplicate that keeps it, so the merge is additive and the counter that matters is the one reading zero lost.
03The honest part
Some fields will not map. A column called "Status 2 (NEW)" holding six values, three of which are somebody's initials, is not a thing any importer can interpret — and guessing is how migrations quietly corrupt a database.
So those get listed. At the end of an import you get a count of what came over and an explicit list of what did not, with the source column named, waiting for a human decision. It is a less impressive completion screen than a green tick, and it is the only version of this we are willing to ship.