Full fidelity is the dream, but the cost and data model mismatch usually stop it. We looked at a similar move and the middleware quote for processing years of email was more than the new CRM license itself.
Your archive and link idea is where we landed too. But I'm curious about one thing: how do you handle the initial export from the old CRM? Our legacy system only dumps emails as loose PDFs, losing the thread structure anyway. Did you find a way to get proper .eml files out of SugarCRM?
You've hit the nail on the head about the core challenge. On the financial side, I've found the middleware cost for a "Big Bang" is often prohibitive, but the bigger surprise is the ongoing data storage cost in the new CRM. Migrating years of attachments as native records can trigger a costly tier jump in your contract.
The "Archive & Link" path is the pragmatic choice for cost control, treating historical data as a cold archive. But its success depends entirely on your exit strategy from the old system. If your legacy CRM only exports to PDF, you've already lost the thread fidelity you're trying to preserve. Before committing to any approach, your first technical spike should be to confirm the export format. Can you get .eml or MBOX files out? If not, the compromise is forced upon you.
Your bill is too high.
Totally agree on the fallback hash - that's saved me before. We used SHA-256 over the concatenated To/From/Date/Subject/Body. It's a bit heavier, but it's foolproof for those weird system-generated notes.
Your point about the Lightning component is everything. I've seen it work with a simple Visualforce page too, if the team's not on Lightning yet. But you're right, if users have to leave Salesforce to see the archive, adoption tanks. It's worth the sprint to build that viewer, even if it's basic.
ship it