HubSpot to Attio: what actually breaks in a migration (and how to move without losing history)
A practitioner's guide to migrating from HubSpot to Attio. What carries over cleanly, what quietly breaks, and the order of operations that keeps your deal history and reporting intact.
Most HubSpot to Attio migrations do not fail on the data transfer. They fail on everything around it.
The records move. Contacts, companies, deals, notes, owners. That part is close to mechanical. What breaks is the stuff nobody checks until it is already broken. Associations. Custom field logic. The three reports the sales team actually opens every morning.
I have run enough of these now to know where the bodies are buried. Here is the honest version.
What carries over cleanly
Start with the good news, because most of your data is fine.
- Core records. Contacts, companies and deals map almost one to one. Attio’s object model is close enough to HubSpot’s that the shapes line up.
- Notes and activity. Emails, calls, meeting notes, the timeline. It moves.
- Owners. As long as the user accounts exist on the Attio side first, ownership transfers with the record.
- Custom fields, mostly. Text, number, date, single select. These come across without drama.
If your HubSpot instance is a fairly standard CRM with some custom properties, you are looking at a clean move for the bulk of it.
What quietly breaks
This is the part worth reading twice.
Associations. In HubSpot a deal is linked to a company and to one or more contacts. Those links are their own objects under the hood. If you export a flat CSV of deals and import it into Attio, the deals arrive with no memory of who they belong to. They look fine in a list. Then someone opens a company record, sees no deals attached, and you spend a week rebuilding relationships by hand.
Map associations before you move anything. Every deal to its company. Every deal to its contacts. Sign it off on paper first.
Multi-select and dependent fields. HubSpot lets you build properties that depend on other properties. Attio handles this differently. Anything with conditional logic needs rethinking, not copying. Sometimes that is a chance to delete a field nobody has used since 2023.
Workflows. They do not migrate. At all. Your HubSpot automations are HubSpot’s. Every lead-routing rule, every deal-stage trigger, every internal notification gets rebuilt on the Attio side. This is not a bug, it is the reality of moving between two different systems. Budget for it.
Reporting. The dashboards do not come with you. The data they sit on does.
The trap is treating a migration as a copy job. It is not. It is a chance to rebuild the data model you wish you had, on a system that lets you shape it.
The order of operations that works
The sequence matters more than the tooling. Get this order wrong and you create work for yourself that did not need to exist.
- Read the existing model first. Before anything moves, map every object, every custom field, every association in HubSpot. You cannot migrate what you have not understood.
- Design the target model in Attio. Not a mirror of HubSpot. The model you actually want. This is where custom objects earn their place, and where you decide what to leave behind.
- Set up users and owners. So ownership has somewhere to land.
- Migrate core records with associations intact. Companies, contacts, deals, and the links between them. Verify the links, not just the record counts.
- Run a parity check. Same number of deals. Same pipeline value. Same open count. If the numbers do not tie out, stop and find out why before the team touches it.
- Rebuild workflows and reports last. Once the data is trustworthy, wire up the automations and the three reports people actually use.
The parity check at step five is the one most people skip. Do not skip it. It is the difference between a migration the team trusts and one they quietly work around.
When you should not migrate
Half the value of doing this for a living is telling people when not to.
If you are on HubSpot Starter, it works, and the only complaint is that you have outgrown a couple of fields, you might not need to move at all. You might need a data layer built on top of what you already run. Fix the enrichment and the routing, stay where you are.
The move makes sense when the CRM itself is the constraint. When you cannot shape the data model without a consultant. When the Professional tier pricing has stopped being worth it. When you want custom objects that match how you actually sell, and HubSpot keeps forcing you into its shape instead.
That is the real trigger. Not the price. The price is a nice-to-have. The data model is the whole thing.
What good looks like on the other side
A working Attio workspace with your data, your history, and your associations intact. A pipeline that ties out to the pound against what you left behind. The reports the team relies on, rebuilt and trusted. Automations that match your motion, not HubSpot’s defaults.
And a data model you can change yourself, on a Tuesday afternoon, without opening a support ticket.
That is the gap I work in. If you are staring down this move and want a straight answer on whether it is worth it for your setup, book a short call. I will tell you honestly, including if the answer is to stay put.