Migrations rarely fail on the day. They fail eleven months later, when somebody asks a question the data cannot answer and the trail goes cold at the import.
Here is what we would do differently, drawn from the ones that went well and the two that did not.
Object by object. Contacts, companies, deals, tickets, products. For each one, name the system that wins when they disagree, and write it down where both teams can see it.
Teams skip this because it feels obvious until it isn't. If Salesforce stays for finance and HubSpot runs marketing and sales, you need to know today which one owns company name, because in eighteen months you will have two and a dispute.
The instinct is to bring everything, because deleting feels risky and storage is cheap. The cost lands elsewhere. Every dead field is a field somebody has to consider, every stale contact damages your deliverability, and every legacy property makes the new portal harder to learn.
Our rule: bring contacts with activity in the last 24 months, all companies attached to those contacts, all open deals, and closed deals for the last three years. Archive the rest somewhere you can query. Nobody has ever asked us to go and get it.
The same goes for properties. If a field has no value in 90% of records and nobody can name the report it feeds, it does not come.
This is the boring one that causes the most damage. Legacy systems accumulate picklist values: eleven lead sources, four of which mean the same thing, two of which are typos.
Migrating them as-is means importing the mess. Collapse them first, in a spreadsheet, with the sales lead signing it off. Then map old to new explicitly, and keep the original value in a read-only legacy property so you can audit later.
Import into a sandbox, then have two or three people who actually use the system try to do their job in it for a day. A real day, rather than a demo.
They will find things no mapping document surfaces: the report a director opens every Monday that depends on a field nobody mentioned, the filter that quietly assumes a naming convention. Fix those before cutover, not after.
Big-bang weekends are how you end up with a sales team locked out on quarter end. What has worked for us:
Move marketing first: contacts, email, forms, tracking. Run a fortnight and confirm the data is arriving correctly. Then deals and pipeline, with a fortnight of dual reporting where both systems are compared weekly. Then switch off the old reporting once the numbers agree. Then, and only then, decommission.
Dual running feels wasteful and it is the cheapest insurance in the project.
The first week live generates a queue of small, urgent things: a workflow firing twice, a form routing to the wrong owner, a property that did not populate. None are disasters and all are loud.
Have someone with admin rights available, all week, with nothing else booked. Migrations that are judged badly are almost always ones where the team went quiet at the moment users needed them most.
Write the runbook as you build. Every workflow, every integration, every property that is not self-explanatory, documented at the moment it is created. Retrospective documentation does not happen.
Keep a frozen export of the source system. A full CSV dump from the day before cutover, stored somewhere safe. It has been needed twice in six years, and both times it settled an argument in ten minutes.
Migration is a project with an end date, which makes it a good way to see how an agency works before committing to anything longer. It is one of the three shapes on our pricing page, and the detail sits on the HubSpot page.