2. 核心银行迁移基础
核心银行系统迁移不是一次简单的“数据搬运”，而是一场涉及业务连续性、账务准确性与监管合规的系统工程。理解迁移类型、掌握迁移流程、认清数据质量在其中的角色，是做好数据质量验收的前提。本节将围绕这四个方面展开，帮助学员建立迁移全局观。
一、迁移类型：不同场景决定不同验收策略
核心银行迁移按对象和目的可分为多种类型，常见的有以下几类：
- 系统替换型迁移：从旧核心系统整体切换到新核心系统，数据全量迁移，通常伴随产品、参数、账务模型的重新设计，风险最高。
- 版本升级型迁移：同一厂商系统从低版本升级到高版本，数据结构变化相对可控，但需关注补丁与历史数据兼容性。
- 平台/数据库迁移：如从大型机迁移到开放平台，或从Oracle迁移到分布式数据库，重点在于数据类型映射、精度与性能。
- 合并整合型迁移：多家机构合并后数据归并，涉及客户、账户、交易去重与冲突消解，数据质量挑战最大。
- 部分业务迁移：仅迁移某类产品（如贷款、理财），边界清晰但接口依赖多。
不同类型决定了数据质量验收的侧重点：系统替换型关注全量一致性，合并整合型关注去重与主数据，平台迁移关注类型与精度。验收方案必须与迁移类型匹配。
二、迁移流程：从计划到切换的六个阶段
核心银行迁移通常遵循以下阶段，每个阶段都有数据质量活动嵌入：
- 迁移规划：确定范围、目标、时间窗、回退策略，识别关键数据实体。
- 数据探查与清洗：对源系统数据做 profiling，发现空值、重复、格式异常，制定清洗规则。
- 映射与转换设计：建立源到目标的字段映射，定义转换逻辑、默认值、异常处理。
- 迁移开发与试跑：开发ETL/迁移程序，进行多轮试迁移，验证数据量与业务规则。
- 数据验证与验收：执行对账、抽样、业务场景验证，确认数据质量达标。
- 切换与上线：正式迁移、增量追平、切换窗口操作、上线后监控。
数据质量验收不是最后一步，而是贯穿全流程。越早发现数据问题，修复成本越低。试跑阶段是发现质量问题的黄金窗口。
三、数据质量在迁移中的角色：从“搬运”到“可信”
数据质量在迁移中扮演三重角色：
- 准确性守门人：确保迁移后余额、交易、客户信息与源系统一致，账务平衡。
- 业务连续性保障：数据错误会导致交易失败、利息计算错误、报表失真，直接影响客户体验与监管报送。
- 风险控制手段：通过质量规则提前拦截脏数据，避免污染新系统。
常见的数据质量维度包括：完整性、准确性、一致性、唯一性、及时性、有效性。在迁移中，一致性（源目标对账）和准确性（金额、日期、状态）最为关键。
四、常见风险与误区复盘
根据大量迁移项目复盘，以下风险与误区最为典型：
| 风险/误区 | 表现 | 后果 | 应对建议 |
|---|---|---|---|
| 源数据质量差 | 空值、重复、格式混乱 | 迁移失败或数据失真 | 提前profiling，制定清洗规则 |
| 映射遗漏 | 字段未映射或默认值错误 | 业务字段丢失 | 映射评审+试跑比对 |
| 对账不充分 | 只对总量不对明细 | 隐藏差异上线后爆发 | 总分核对+抽样明细 |
| 增量追平失败 | 切换窗口增量丢失 | 交易丢失、账务不平 | 增量机制演练+回退预案 |
| 忽视历史数据 | 只迁当前余额 | 无法追溯、审计失败 | 明确历史数据保留策略 |
最常见的误区是“先迁过去再说，有问题上线后修”。核心银行数据一旦污染，修复成本极高，甚至影响监管评级。数据质量验收必须前置，且要有明确的准出标准。
五、迁移数据流与质量检查点
下图展示了核心银行迁移的典型数据流与关键质量检查点，帮助学员直观理解数据从源系统到目标系统的流转路径，以及每个环节应关注的质量控制点。
从图中可以看出，数据质量检查点并非集中在迁移末端，而是分布在源系统、清洗、转换、目标系统四个关键位置。每个检查点都有明确的准出标准，只有全部达标才能进入下一阶段。
六、案例场景：某银行核心迁移的数据质量教训
某城商行在核心系统替换迁移中，试跑阶段只核对了账户总数和总余额，未对明细交易做抽样比对。上线后发现部分贷款账户的利率字段被默认值覆盖，导致利息计算错误，影响数千客户。事后复盘发现，映射文档中利率字段的转换规则缺失，而验收环节仅做了总量对账，未做字段级抽样。这个案例说明：总量一致不等于数据正确，字段级验证不可省略。
建议在验收中采用“三层验证法”：第一层总量对账（账户数、余额、交易笔数），第二层字段级抽样（关键字段逐笔比对），第三层业务场景验证（利息计算、报表取数、交易流程）。三层都通过，才能判定数据质量达标。
综上，核心银行迁移的数据质量验收必须建立在对迁移类型、流程和风险的清晰认知之上。只有把数据质量活动嵌入迁移全流程，设置明确的检查点和准出标准，才能确保新核心系统上线后账务准确、业务连续、监管合规。