答案。

在信息技术的全球经验中，数据迁移的任务往往成为意外故障的源头：数据扭曲、丢失或重复，尤其是在大型、异构的信息环境中（例如，从单体转向微服务或从传统平台转向现代解决方案时）。

问题在于缺乏对迁移的统一理解：客户或开发人员常常仅将此任务视为技术性任务，未评估对业务流程的风险，也未考虑边界情况（数据格式、结构的不匹配，失去旧系统中的一次性业务规则）。

解决方案在于系统性的方法：

• 完全清点数据模型，包括不明显的联系和业务规则。
• 制定详细的迁移场景：历史数据、非 актуальные、孤立数据的处理方案。
• 在迁移需求文档中明确文档，包括加载顺序、回滚方法、完整性和正确性检查。
• 确定风险区域：哪些数据不被迁移，为什么，如何记录。

关键特点：

• 需要业务分析师、架构师和数据库管理员之间的紧密沟通。
• 始终增加迁移验证步骤（例如，选择性复制和后续审计）。
• 分面（逐步）文档记录：完全迁移、部分迁移以及需手动处理的内容。

有陷阱的问题。

在“数据库中一切都存在”的情况下，是否可以在没有业务部门参与的情况下进行数据迁移？

不可以，在没有业务参与的情况下，无法确定数据的有效性、关键性和准确性。即使没有正式描述，旧的业务规则也可能影响信息的生命周期。

是否必须保留旧数据模型中的所有字段在新系统中？

并不总是：某些字段可能是陈旧的或失去意义的。然而，这一决定应当达成一致并记录在文档中，否则将存在业务流程不一致的风险。

是否可以只进行“新鲜”数据的选择性迁移？

这取决于业务需求。历史数据通常在报告、合规或审计中是必要的。未经协调的选择性迁移可能导致法律或操作信息的丢失风险。

常见错误和反模式

• 缺乏数据转换规范（哪些字段被转换以及如何转换）。
• 跳过影响下游流程的属性。
• 忽视迁移后的重新测试和审计跟踪需求。

生活中的例子

负面案例： 银行过渡到新的CRM系统；分析师没有记录客户所在城市与地区税收优惠之间的关系。这导致奖金计算中的错误。

优点：

• 解决方案的快速实施。

缺点：

• 对客户的赔偿金额达到数千。
• 法律风险和客户信任的丧失。

正面案例： 在迁移之前，分析师创建了详细的属性地图，进行了数据的试点筛选和导出，测试了随机客户每笔交易的正确性，并与业务和审计团队协商了所有场景。

优点：

• 最小化错误。
• 快速响应事件。

缺点：

• 准备阶段更长。