数据迁移在企业管理系统选型里有个尴尬的位置：它几乎从不出现在报价单的显眼处，却总在项目推进到中后段时，变成拖慢进度、追加预算的那一项。签约前把它当作“搬数据”的技术收尾，签约后才发现它牵动的是需求边界、责任划分和上线时间。
成本被低估，首先源于一种直觉性的误判：旧系统里的数据看起来就在那里，导出再导入似乎只是操作问题。但企业历史数据的真实状态往往并不整齐——同一客户在不同表里名称不一致，关键字段长期靠人工备注补全，历史单据缺少必要的关联关系。数据越乱、格式越不统一，迁移越费劲。这种“乱”在选型阶段很难被完整看清，因为要看清楚它，本身就需要投入梳理工时。
第二个原因在于，迁移从来不是纯技术动作，而是一次业务规则的重新对齐。新系统的字段定义、权限颗粒度、审批逻辑与旧系统未必一致，旧数据要落进新结构，就必须先回答“这条历史记录归谁看”“这个状态在新流程里对应哪一步”。这些问题属于业务判断，不属于开发工作，却直接决定迁移方案的工作量。需求没定就签约时，这部分工作量往往被双方同时忽略。
第三个原因更隐蔽：迁移的责任边界在合同里常常是模糊的。老系统里的历史数据要搬到新系统，这件事的工作量经常被低估，签约时最好把这块单独写清楚由谁负责。现实中的常见情形是，甲方默认乙方负责，乙方默认甲方提供干净数据，等到真正开工，才发现双方对“干净”的定义完全不同。责任一旦悬空，补位的一方就要付出额外成本。
从预算结构看，迁移成本还容易被总价掩盖。两份报价差一倍，很可能不是一家贵一家便宜，而是一家含了需求梳理、数据迁移、培训和一年维护，另一家只报了个开发费。当迁移被拆散隐藏在“实施服务”或“上线支持”里，它既无法被单独比较，也无法被单独追责，自然也就难以被准确估价。
真正把这项成本压下来的做法，是在签约前把它显性化：明确迁移哪些数据、由谁清洗、以什么标准验收、异常数据如何处理。需求模糊的时候，谁都报不准价；清单越清楚，后期扯皮越少。数据迁移的代价，本质上不是技术难度，而是它把选型阶段所有没想清楚的问题，都推迟到了上线前才集中暴露。
