Cookbook
Move over from HubSpot
A migration with no importer, which sounds worse than it is. The agent that reads your export is the same one that will run the CRM afterwards, and it is better at this than a column mapper.
The situation
You have years in another CRM. Companies, contacts, deals, a pipeline somebody configured in 2022, forty custom properties of which six are used, and a lot of activity history.
There is no import wizard here. What there is instead: an agent that can read a CSV, understand that "Acme Corp." and "Acme Corporation" are one company, and ask you about the six things it genuinely cannot decide. That is a better tool for this job than a column mapper, and the reason is that most migration pain is not mapping, it is judgement.
What must be true when you are done
- Everything you need to work Monday is in, and you know what is not.
- Deals sit in stages you chose, in a pipeline you designed.
- Nothing arrived twice.
- Every imported value is marked as imported, so it is distinguishable from anything checked since.
- You can re-run the whole thing after fixing the source, safely.
Decide what not to bring first
The most valuable hour of a migration is the one spent deciding what to leave behind.
Everyone brings everything, because it feels safer, and then the new system is the old system with a different login. The things worth leaving:
Custom properties nobody fills in. Export the fill rate. Anything under about a fifth is a field somebody added once, and bringing it forward means maintaining it forever on the strength of forty rows.
Contacts with no activity in three years. They are not a book of relationships, they are a mailing list, and they will distort every count you take.
Closed-lost deals from before this year. Keep the reasons if you have them, as a note. The records themselves buy nothing.
Every logged email. This is the big one and the one people flinch at. Years of raw activity rows do not become useful history, they become a feed nobody reads. Bring the interactions that carry a decision, and let the rest go.
The order, and why it is this order
| Step | Why here |
|---|---|
| Companies | Everything else points at them. Get the domains right and most of the rest lands by itself. |
| Contacts | Matched on email, attached to companies by domain. |
| The pipeline | Your stages, before any deal arrives, so nothing lands in a default you did not choose. |
| Open deals | The ones that matter. Amount, close date, stage, company. |
| Closed deals from this year | Enough history to forecast against. Older than that is usually nostalgia. |
| Interactions worth keeping | Not all of them. This is the step to be ruthless about. |
The pipeline before the deals is the one people invert, and it is expensive: import deals first and every one of them lands in the default pipeline, and moving them afterwards is a stage change on every record rather than a decision made once.
Run it in batches, and read the first one
You
Here is companies.csv from HubSpot. Load the first fifty as a test: match on domain, mark everything imported, and skip any row with no domain and tell me about it. Then stop and show me what you did.
Fifty first, always. What you are checking is not whether the tool works, it is whether your export means what you think it means. The usual surprises are a domain column containing full URLs, a company name column containing the contact's name for sole traders, and a currency that is not the one you assumed.
When the fifty look right, the rest is one instruction. Re-running is safe, so a batch that fails halfway is not a problem: point it at the same file again and only what is missing gets written.
Expect the conflict report, and use it
A real export contradicts itself, and you will get a list of the places it does. That list is the most useful artifact of the whole migration.
Agent
Those are not import errors. They are two records in your old CRM that disagreed, surfaced at the one moment somebody is looking. Fix the source, re-run, and the list gets shorter. The import recipe covers this in detail.
The things that do not come across
Stated plainly so you meet them now rather than in week two.
Workflows. There is no workflow builder to import into. What replaces them is a split between an agent and your own automations, and it is worth reading before you migrate rather than after.
Sequences. No drip engine, and nothing here replaces one. If your motion depends on automated multi-touch outbound, that stays where it is and Indraft is where the results land.
Dashboards. There is no dashboard builder. You ask questions instead, and get numbers computed over every record rather than over the page of records something happened to fetch. If the dashboard you will miss is the forecast, that one is a single call and it is written down: weight the pipeline, and check last month's call.
Your custom objects come across as your own types, which is the one that usually goes better than expected. Define the type before importing its records.
Verify the migration
- Count against the source. Companies, contacts, open deals, and the sum of open pipeline. The sum is the one that catches a currency assumption.
- Open your five biggest accounts. Not a sample, those five specifically. If they look right you will trust the system, and if they do not you will not, whatever the counts say.
- Run the duplicate survey. A migration is where duplicates arrive, and finding them is easier on day one than in month three.
- Ask what nobody has checked. Everything, on day one, because it all came from a file. That is the honest starting position.
Run it again
Keep the old CRM read-only for a month rather than cancelling it. The re-run is cheap and you will want it twice: once when you find the currency thing, and once when somebody asks for a field you decided to leave behind.