北京
做过CRM迁移的人都知道，最痛苦的不是写导入脚本，是处理那些号称"标准导出"的CSV文件。我帮家政服务公司做系统切换，从Honeybook、Dubsado、17hats三个平台往外搬数据，每个都有自己的"惊喜"。
这些平台的导出文件有个共同点：技术上确实给了数据，但格式之混乱，让pandas的默认读取直接崩溃。Phone number带格式字符、日期时区不标注、富文本里塞原始HTML——你以为在迁移客户关系，其实是在做数据考古。
Honeybook的导出是个zip包，拆开是多个CSV：联系人、项目、付款记录、文件。但引号处理不一致，老版本导出尤其混乱。必须用python引擎读取，dtype全设成字符串，编码指定utf-8-sig才能去掉它偷偷加的BOM。Phone number是带括号和横线的字符串，project status用内部代码，notes字段可能藏着富文本编辑器生成的HTML。
Dubsado更折腾。没有一键导出，Clients、Projects、Leads、Invoices要分别点。Clients表的tags列是逗号分隔的字符串——逗号分隔文件里再嵌逗号，引号包裹还不稳定。最头疼的是自定义字段，用户 intake form 里加什么，列名就叫什么。我见过60多列的导出，因为客户把表单设计得太"有创意"。
17hats的字段命名直接让人怀疑人生。Contact identifier不叫contact_id，叫"Contact #"——带空格和井号的那种。Phone列可能塞多个号码，用斜杠或"alt:"前缀分隔。这些细节不会写在文档里，只有真动手迁过才会发现。
三个平台的脚本我都开源了。核心思路一样：不信任任何类型推断，全部按字符串读；把非标字段坍缩进notes字段；日期手动解析并补时区。客户通常不关心自定义字段能不能原样迁移，他们只想在新系统里能搜到旧记录。这个需求听起来简单，但原始数据的脏度，让实现成本翻了不止一倍。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
