数据量小且干净：一到两周。不干净：两到四个月。谁在没看过真实数据之前就报出迁移工期，谁就是在猜。
三个区间，覆盖几乎所有项目小而干净：1–2周。5万行以内，只有一个来源——一份电子表格或一个旧系统——每个客户都有唯一编号，日期是真正的日期类型。大部分时间花在核对上，而不是搬运上。中等：3–6周。几个来源要合并：这边一份表格，那边一个旧开票工具，再加上邮件平台导出的数据。一部分记录是脏的，来源之间还互相矛盾。混乱：2–4个月。没有唯一编号，同一个客户被录成三种写法，日期是随手打的文字（“三月初”“3/4/21”——三月还是四月？），备注栏里塞满了本该单独建列的数据。数据量没有大多数人想的那么重要。50万行干净数据，比2万行混乱数据迁得更快。
传输是最便宜的环节把5万行数据拷进新数据库，用不了一个小时。如果迁移只是传输，所有项目一周都能收工。
真正吃时间的是清洗和对账。判断“宏达贸易有限公司”“宏达贸易”“hongda”是不是同一个客户——还要拿出依据，因为把两个其实不同的客户合并掉，比留着一条重复记录更糟。解析4000条自由文本日期，把其中300条有歧义的挑出来交给人工判断。把旧系统的未收款总额和新系统对平，查清为什么差了2800元。光最后这一步，经常就要整整一周。
在混乱的项目里，大约70%的工作量花在数据质量上。真正搬数据的代码，大概只占15%。
预留试运行和并行期负责任的迁移从来不是周五关机、周一开机，而是分三步走：
试运行。把数据完整迁进新系统的测试副本，核对行数、合计数，再抽查一批真实记录。什么都不上线。做好跑两三轮才能跑干净的准备。并行运行。一到两周内两套系统同时在用。员工在新系统里干活，旧系统作为参照，月底合计数拿来对比。细微的错误就在这个阶段浮出来——那种任何自动校验都抓不到的错误。正式切换。并行期对得上账，才切换。让旧系统保持可查，再留几个月不要在上线当天退掉旧软件的授权。让它以只读模式再跑三到六个月。总会有人要查一条你决定不迁的记录——没有人会迁移全部数据，旧报价、死掉的线索、2019年的附件通常都留在原地。真遇上税务问题或客户纠纷，原始数据就是你的凭证。只读访问一般只要全额授权的零头，它能把“那条记录丢了”变成“给我五分钟”。
什么会让报价变动四个问题决定你的项目是两周还是两个月：
记录有没有唯一编号，还是只能靠姓名加电话去匹配客户？要合并多少个独立来源？日期、金额、状态存的是真正的数据类型，还是自由文本？你们这边有没有人能在一天内回答“这两条记录哪条是对的”，还是每个问题都要等一周？最后一条是隐形杀手。技术活可以很快，等决策才是把六周的项目拖进第四个月的原因。
接受任何工期之前，先把一份真实的数据导出发给开发者看。对着真文件看十分钟，胜过空谈一小时。