悟空CRM的老数据搬过来，麻烦在哪几处
悟空CRM 是国内开源的 CRM 里用得比较多的一个，自装版能自己部署，数据在自己服务器上。用两三年之后想换，问题就来了：老数据怎么搬。
先说结论：客户、联系人、商机这三张表好搬，跟进记录和附件不好搬，审批流和历史权限基本搬不动。
好搬的部分
客户表的结构是所有 CRM 里最像的：名称、电话、地址、归属人、创建时间。这几列对应到新系统的客户字段，一对一。
商机表稍微麻烦一点，因为阶段名称各家用得不一样。搬家之前要做一件事：把老系统的阶段名和新系统的阶段名做一张对照表，比如"初步接洽"对应"信息核实"，"方案报价"对应"方案提交"。
这张对照表不做，搬完以后漏斗图会变形，谁也看不懂。
不好搬的部分
跟进记录是自由文本，长度不限，还带附件。导出的时候一般能拿到 CSV，但附件是一条一条的链接，得单独下载再重新上传。
如果记录量在几千条，建议只搬最近一年的。三年前的跟进记录，实际使用频率极低，搬过去只是占地方。
附件这一块要有心理准备。老系统里的附件往往存在服务器目录里，路径和记录 ID 对应，整理成可导入的格式要写脚本。没有技术人员的公司，这一步会卡住。
搬不动的部分
审批流和历史权限，这两样基本只能重建。
审批流在老系统里是一套流程定义，新系统是另一套。能做的是把审批的规则抄下来（谁审、金额分级、会签还是或签），在新系统里重新配一遍。
历史权限更麻烦。老系统里谁看过哪些客户，这个信息一般不留存。搬过去以后按新规则重新分配，这事得业务负责人拍板，不能交给 IT。
迁移的实际顺序
顺序有讲究，跳步会更费时间。
先导出客户表，去重，清洗名称。这一段最花时间，占到整个活儿的六成。
客户导进去之后核对数量。进一千条出来九百八，少的二十条要查原因，多半是手机号格式或者必填字段为空。
联系人和商机跟着进，靠那张阶段对照表对齐。
跟进记录只搬近一年，附件这一类单独处理。
最后并行四周，老系统设成只读，别再往回写。
几个具体的坑
手机号格式。老系统里可能有带空格、带横线、带 +86 的写法，导入前统一成纯数字，否则去重和查重都会失效。
归属人。导入的时候归属人字段要对应到新系统的员工账号，账号没建好就导，所有人都会变成管理员。
自定义字段。老系统里的自定义字段名如果带特殊符号，导入会报错。改干净再导。
时间字段。创建时间是系统自动生成的，导入时能不能指定，各家不一样。不能指定的话，所有客户都会显示成同一天创建，客户画像里的时间维度就废了。
开源自装和云版的区别
悟空CRM 有自装版和云版两条路。自装版数据在自己手上，但升级、备份、安全都得自己管；云版省事，数据在服务商那里。
从自装版往云端 CRM 搬，和技术难度无关，和决心有关。真正难的是让人改掉旧习惯。
数据迁移的通用路径，另有一篇写在免费CRM；如果是为了项目型业务换系统，看项目制销售CRM。
最后一句。迁移方案写得再细，第一次导入一定出错。留出两周返工时间，别把上线日期卡在季度末。
还有一件事别忘了做：迁完以后，把老系统的数据库完整备份一份，存到你确定三年内不会动的地方。
还有个容易忽略的东西：二次开发留下的字段。
开源自装版常见的情况是，前几年业务提需求，技术加了一批字段，有些字段后来没人用了，但表结构还在，导出的时候也带着。这些字段到新系统里没有对应，硬导会报错，不导又会丢信息。
处理办法是先做一次字段盘点。把每个字段的用途问一遍，能说清用途的留下，说不清的列进"待定"清单，业务确认后再决定。这个过程看着慢，能省掉后面一半的返工。
验证搬得对不对
搬完不能只看条数。
抽三十条客户，逐条比对：名称、电话、归属人、创建时间、最近一条跟进记录的日期。三十条里有三条以上对不上，说明规则有问题，得停下来改。
金额类的数据要单独核对。商机的预计金额、订单的实际金额，这两类数对不上，后面的报表全歪。
培训比迁移更容易被低估
新系统上线，销售的第一反应是找老系统。这个惯性会持续两到三周。
对策是把老系统设成只读，并且明确说清楚什么时候关。含糊其辞最糟，人会觉得"反正还能用"。
培训内容也要克制。第一周只教三件事：怎么建客户、怎么写跟进、怎么看自己的客户列表。其余的功能等他们用熟了再说。
成本要算全
迁移这件事的显性成本是软件费，隐性成本是人力。
一个中型公司的迁移，业务侧投入大概在六十到一百个工时，技术侧看数据复杂度。这些工时不会记在项目预算里，但它真实存在。
把它算进去，你对"值不值"的判断会准一些。
