Hi everyone! I've been lurking for a bit, but this is my first post here. I'm a marketing ops manager, and we're finally moving off our legacy CRM (a very old Salesforce org) to HubSpot later this year. I'm helping with the marketing side of the migration, but I'm getting really worried about the sales data.
Our sales team lives and dies by the activity history in Salesforce—every call log, email sent from the CRM, and internal note on an account. They use it for forecasting, understanding deal context, and onboarding new reps. I've heard horror stories where this stuff gets flattened into a single "notes" field or lost entirely.
My specific questions are:
- What's the actual, practical method for moving this kind of relational activity data? Do you export it all and try to recreate the links in the new system, or is there a better way?
- For synced emails (ones sent via the CRM's email integration), do you typically just bring over the metadata (date, subject, contact) or the full body? What have you found most useful?
- Did any of you use an interim "data lake" or staging area? I'm thinking we might need to cleanse and map the data before the final import, but that sounds complex.
I'd love to hear concrete examples of what worked and what broke. For instance, did your call logs retain their "outcome" status? Did notes retain their original authors and timestamps, or did they all get attributed to the migration user? 😬
This feels like the make-or-break part of the move for user adoption. Any step-by-step advice from your own migrations would be incredibly appreciated!
Your concern about flattening relational data is valid - I've seen migrations where the activity timeline becomes an unusable blob. The practical method often involves extracting the entire graph: Tasks, Events, EmailMessages, and Notes, along with their junction objects to Contacts, Leads, and Opportunities. You'll need to preserve the foreign keys as custom fields in HubSpot during migration, then remap the relationships using HubSpot's API to establish the new native associations. A direct export/import rarely works.
On your data lake question: absolutely use a staging area. It's not overkill. We typically land the raw Salesforce extract in a cloud database (BigQuery or Postgres), apply transformations for field mapping and data cleansing, then push to the target system. This gives you a rollback point and lets you validate the relationships before the final cutover. The complexity is upfront, but it prevents a scenario where your sales team loses trust because their historical context is garbled.
For synced emails, bring the full body if possible. Metadata-only strips the nuance from prior conversations. Storage is cheap; losing deal context is expensive.
user89's advice on the staging database is technically correct, but it misses a major operational risk.
The real failure point isn't the tech. It's the timeline and scope. Cleaning and mapping a decade's worth of call logs and email syncs is a massive manual effort. Your sales team will expect to search this history on day one in HubSpot. If it's a mess, they'll stop trusting the new system immediately.
On synced emails: always bring the full body. Metadata is useless when a rep needs to see what a client agreed to three years ago. HubSpot's activity timeline can handle it, but you need to map the "related to" IDs perfectly.
Budget 3x the time you think you'll need for data validation alone. And do a pilot with one sales rep's entire history before you move everything. Let them try to find a specific note from 2020. If they can't, your process is broken.
Agree on the staging database. I'll add you need to validate data lineage and access during that phase. I've seen migrations where the exported activity data still had field-level security or sharing rules attached, so it looked complete in the staging area but was actually missing records for certain teams.
For synced emails, bring the full body but also the headers if you can. Those sometimes contain original message IDs or routing info that becomes critical for compliance audits later. You're not just moving data, you're preserving evidence.
user367's point about scope is the real killer. The technical extract is straightforward. The political fight over what "clean" data means will take months.
patch early
Welcome to the community, and great first post. You're right to be worried, but focusing on it now is smart.
You've already gotten good technical advice, so I'll add this from a community health angle: guard against scope creep disguised as "cleanup." Every migration has people who want to use it as a chance to "finally fix" years of bad data entry. That's a project killer. Your goal is fidelity - moving the history as it exists, not as someone wishes it existed. The "political fight over what 'clean' data means" that user390 mentioned can derail everything if you let it.
Define a clear, narrow standard for what constitutes corrupt data that must be fixed (like malformed email addresses that break imports) versus "messy" data that gets moved as-is. Get sales leadership to sign off on that distinction early. It'll save you months.
Be excellent to each other