一次从Salesforce迁到HubSpot的项目，我原本以为最麻烦的是字段映射和CSV清洗。结果这两件事都不算难。真正棘手的问题出现在处理历史支持数据的时候：53640个案例相关文件必须保持可理解、可追溯，而迁移进行到那个阶段时，目标系统里只有770张对应的支持工单。

CSV能迁移属性，但它不会自动保留记录、附件、导出文件以及另一平台中代表该记录的对象之间的关系。解决办法是停止把这些文件当成一堆附件，先建一个明确的身份层：源案例编号 → 源记录 → 导出文件 → 目标工单。这份清单成了后续迁移的控制平面。

打开网易新闻 查看精彩图片

我原以为CSV会是最难的部分

迁移一开始和大多数CRM迁移一样：盘点Salesforce对象，决定哪些还有用，清洗数据，映射字段，把记录导入目标系统。账户、联系人、线索这些结构化对象虽然繁琐，但能理解。你可以打开CSV查看自己手里有什么。

历史支持案例不一样。Salesforce导出分散在多个归档里，结构化CSV数据旁边是成千上万个与历史案例关联的物理文件。盘点结束时，案例文件数量是53640个。目标端当前迁移范围内有770张HubSpot工单。问题立刻变了：我不需要盲目搬移53640个文件，而是要为每个文件回答三个问题：

  • 这个文件属于哪个Salesforce案例？
  • 那个案例有没有对应的目标工单？
  • 如果有，怎么把正确的文件挂到正确的工单上，同时不丢失原始身份？

这不是CSV导入问题，是身份映射问题。

Salesforce导出保留了数据，但不一定保留使用语境

导出过程中让我意外的一点是，面向备份的表示方式和人想浏览的方式差别很大。Salesforce导出中，物理附件文件可以用Salesforce ID而非原始文件名导出，需要配合元数据CSV才能确定原始名称和文件类型。这对系统导出完全合理，但如果有人六个月后打开归档问“案例001234的PDF在哪”，就不方便了。

一个目录里放着类似这样的文件：

  • 00P8X00000ABCDE
  • 00P8X00000ABCDF
  • 00P8X00000ABCDG

技术上可能完整，操作上却没法用。所以导出需要一个转换层。但我不想简单重命名然后丢掉Salesforce ID，那些ID是我证明每个文件来源所需的证据。