问题历史：
数据迁移是大型IT项目的关键阶段，尤其是在从过时的信息系统（遗留系统）迁移到新解决方案时。要求形式化中的错误可能导致重要信息的丢失或新系统启动时的长时间停机（尤其是在大规模部署时）。历史上有因迁移失败而导致银行崩溃的悲惨案例！
问题：
源格式和目标格式的不明确、数据结构的差异、目录的不兼容、映射中的错误以及业务团队和技术集成商之间的期望对立是问题迁移的主要原因。虚构或不够详细的文档导致无法追踪哪些数据是关键，哪些数据可以聚合，以及哪些数据根本无法迁移。
解决方案：
系统分析师与业务流程所有者一起对源方的数据进行审查；制定详细的数据映射图，确定哪些属性必须迁移，哪些不必须。记录数据质量的假设（清洁度、完整性），确定转换规则（例如，日期、货币、编码格式的变化）。对于关键字段，实施测试抽样迁移和回检场景。每个阶段同时制定回滚指令和迁移成功标准。
关键特点：
仅仅核对系统之间的数据格式是否足够成功迁移？
不够。即使格式一致，也可能存在数据的业务意义、目录的有效性、值的语义不匹配。需要对每个字段进行业务和技术审计。
只迁移“最需要的”数据是否可以？
不可以。“稀有”数据可能对某些用户流程是业务关键的（例如，旧的合同、保险）。所有内容都应在需求中记录。
是否需要考虑迁移的回滚可能性？
是的——即使经过100%的测试，go-live后可能也会出现关键错误，回滚是文档的必要部分。
**负面案例：**在迁移遗留银行系统时，分析师仅同意迁移主要表格，而未澄清旧的未使用目录的业务意义。结果是，客户在启动后发现过去几年的交易历史出现问题。
优点：
缺点：
积极案例：
分析师与业务和IT共同审查所有数据集，为“稀有”数据迁移制定了单独的要求，商定了验证和回滚场景。迁移顺利完成，没有出现任何关键投诉。
优点：
缺点：