Skip to content
Notifications
Clear all

Anyone else having issues with email history not importing correctly?

2 Posts
2 Users
0 Reactions
2 Views
(@migration_warrior)
Eminent Member
Joined: 2 months ago
Posts: 26
Topic starter   [#2895]

Just wrapped up a migration from Zendesk to HubSpot Service Hub, and the email history import was our biggest headache. The contacts and tickets came over clean, but the threaded email history was a mess—showing up as disconnected, timestamped notes instead of proper email threads. It made the customer context almost useless for our support team.

We followed the vendor's CSV template to the letter, mapping the `message_id`, `in_reply_to`, and `thread_id` fields. The preview looked fine, but post-migration, the threading was lost. After a week of digging, we found the issue: **character encoding on special quotes and line breaks in the email body**.

Our legacy system exported the `body_html` field with Windows-1252 encoding, but HubSpot was expecting UTF-8. The mismatch caused the import tool to silently fail on those records, breaking the thread association.

Here's the PowerShell snippet we used to fix the exports before the final cutover:

```powershell
Get-Content -Path ".email_export.csv" -Encoding Windows1252 |
Set-Content -Path ".email_export_utf8.csv" -Encoding UTF8
```

**Our revised playbook:**
* Extract emails with explicit UTF-8 encoding from the source.
* Run a pre-validation script to ensure every `message_id` has a valid `thread_id` and `in_reply_to` reference.
* Do a **staged import**: contacts first, then a small batch of emails (like 50 records) to verify threading.
* Only then proceed with the full history import.

The whole detour added about three days to our timeline. The actual migration window was 48 hours, but the prep and testing phase ballooned because of this.

Has anyone else hit similar email threading issues? Curious if it's a common pitfall with certain source systems or if you found other workarounds.


test the migration twice


   
Quote
(@observability_owl)
Eminent Member
Joined: 3 months ago
Posts: 19
 

Oh man, encoding issues are the worst. They're so easy to miss in a preview because everything *looks* right, but the underlying data is subtly corrupted. That PowerShell fix is a lifesaver.

We hit something similar migrating ticket logs with emojis in the user comments. The import didn't fail, it just stripped them out, which broke some of our internal sentiment tracking. Now I always run a pre-check for UTF-8 BOM and high-bit characters before any big data import. A quick `file -i` on Linux or checking the hex header can save so much pain.


Silence is golden, but only if you have alerts.


   
ReplyQuote