1. 内容整体设计与思路拆解
1.1 为什么数据初始化是 ERP 替换的第一道坎
华为 MetaERP 替换 Oracle EBS 这件事，在圈子里的热度一直很高。很多人关心的是“自研 ERP 能不能打”“流程怎么重构”，但真正动手做过大型 ERP 替换的人都清楚：方案设计再漂亮，如果数据初始化这关过不去，后面全部白搭。我见过太多项目在蓝图阶段侃侃而谈，结果一进数据迁移就翻车，轻则上线延期，重则账实不符、业务停摆。
数据初始化本质上干的是三件事：把 EBS 里的数据读出来、按 MetaERP 的模型转过去、再验证两边对得上。听起来简单，但放大到华为这样的体量——全球多法人、多账套、多币种、多语言，物料主数据几十万条、未清采购单几十万单、历史凭证上亿行——难度是指数级上升的。更麻烦的是，EBS 和 MetaERP 的数据模型不是一一对应的，很多字段要拆、要合并、要映射代码值，处理不好就是灾难。
还有一个很多人忽略的点：数据初始化不只是“搬数据”，它同时承担着数据治理的使命。EBS 跑了这么多年，里面藏着大量脏数据，比如重复的供应商、失效的会计科目、对不上的成本中心。如果原样迁过去，MetaERP 上线第一天就要消化这些历史包袱。所以一套好的初始化方案，必须把“清洗”和“转换”嵌进流程里，而不是傻乎乎地全量复制。
1.2 初始化方案的整体架构：先切蛋糕，再谈技术
我梳理过这类大型 ERP 替换的初始化工作，正常都会切成四个阶段来做：数据盘点与清洗、技术选型与映射设计、初始化实施、验证与切换。每个阶段都有独立的交付物，不能跳步。
数据盘点阶段的核心产出是一张“数据地图”，搞清楚 EBS 里到底有哪些表、哪些字段、数据量多大、增长速率如何、哪些是主数据、哪些是交易数据、哪些历史数据根本不用迁。技术选型阶段要决定用什么工具来抽取和装载，是直接用 Oracle 的 SQL*Loader，还是用 DataX、Kettle 这类开源 ETL，还是走接口调用。映射设计阶段是最费脑子的，要把 EBS 的字段语义翻译成 MetaERP 能懂的字段语义，包括代码值映射、日期格式转换、金额精度处理、多语言描述处理。
这里有个很关键的原则：初始化方案必须支持“多次预演”。不要指望一次全量迁移就成功，应该是一个“预迁移→校验→修复→再迁移”的循环过程。方案设计阶段就要把断点续传、幂等写入、版本回退这些机制考虑进去，否则每次预演失败都要从头来一遍，代价太大。
我在实际项目里见过一种很实用的分层思路——把初始化工作分成“静态数据”和“动态数据”两条线并行推进。静态数据包括物料、供应商、客户、会计科目、成本中心这类不常变的档案，动静态数据包括未清采购单、未清销售订单、库存余额、总账余额、应收应付余额这类有状态的业务数据。两条线的处理逻辑完全不同，静态数据讲究“全量覆盖”，动态数据讲究“时点快照+增量补充”，分开设计才不会被互相拖累。
2. 核心细节解析与实操要点
2.1 数据盘点阶段的三件套：全表扫描、敏感识别、历史分层
很多人做数据盘点喜欢直接问业务要一份“需要用到的表清单”，这是典型的偷懒思路。业务给出的清单永远不完整，原因是很多数据是模块之间自动传递的，业务自己都不清楚底层逻辑。我建议的做法是直接对 EBS 数据库做全表扫描，把所有表的行数、字段数、主键、外键、索引情况全部拉出来，生成一张数据字典，再和业务清单做交叉比对。
全表扫描听起来工程量大，但实际有技巧。EBS 的数据字典其实很规整，AP、AR、GL、INV、PO、OM、FA 这些模块都有前缀清晰的核心表，比如 AP_INVOICES_ALL、AR_CUSTOMERS、GL_JE_LINES、MTL_SYSTEM_ITEMS_B 这些。先按模块把表分组，再按行数排序，基本上就能锁定 80% 的重点表。剩下的 20% 是自定义表、接口表和临时表，这些需要逐个确认要不要迁。
数据盘点还有一个容易踩的坑：敏感数据识别。EBS 里的员工信息、银行账号、联系人电话、身份证号这类数据，在迁移过程中要提前做脱敏策略设计。特别是华为这种跨国企业，不同国家对个人数据的要求不一样，某些字段在源系统可以明文存储，到了 MetaERP 就要求加密或脱敏。我建议在盘点阶段就生成一张“敏感字段清单”，标注每个字段的敏感级别和处理策略，不要等到迁移中段才发现某个字段不能碰。
历史数据分层是一个让很多项目纠结的问题。我的经验是三层：热数据（近 3-5 年，必须全量迁移）、温数据（5-10 年，按需迁移或压缩存储）、冷数据（10 年以上，只保留汇总数或直接归档）。这个分层标准每个企业不一样，但逻辑是通用的——不是所有历史数据都有业务价值，把冷数据迁进去徒增初始化负担，后续查询效率也会受影响。华为这种体量的企业，历史数据动辄几十 TB，分层决策直接决定初始化窗口的时长。
2.2 静态数据初始化：主数据治理才是重头戏
静态数据初始化看起来最简单，不就是“把档案搬过去”吗？但真正做起来，90% 的时间都花在主数据治理上。物料主数据的编码规则、命名规范、分类体系，EBS 和 MetaERP 几乎不可能完全一致，这就需要一套映射规则。我见过最头疼的情况是：同一个物料在 EBS 里有多个编码（因为历史上有过几次编码规则调整），到了 MetaERP 必须合并成一个主数据记录。
我的建议是：静态数据迁移前必须先做“主数据清洗”，清洗规则和业务部门逐条确认。比如重复供应商合并规则，是按税号合并还是按名称相似度合并；失效物料怎么处理，是打标迁过去还是直接不迁；历史成本中心怎么处理，是保留原编码还是映射到新编码体系。这些决策直接影响迁移脚本的写法和映射表的维护。
另外一个经常被忽略的是“层级关系”的迁移。比如物料分类的树形结构、会计科目体系的层级结构、成本中心的汇报关系，这些在 EBS 里往往通过父子节点关联存储，迁移时要特别注意顺序。先迁根节点，再迁子节点，否则外键约束会报错。批量提交时也要控制切片大小，我一般按 500-1000 条一个批次，既保证效率又不会让数据库锁冲突太严重。
2.3 动态数据初始化：时点快照的艺术
动态数据初始化的核心难题是怎么定格“初始化时点”。一般做法是选一个业务低峰期（比如月底结账完成后的某个时间点），以这个时点做全量快照，然后切换到增量同步模式，把快照之后的业务变化持续搬到 MetaERP。这个“快照+增量”的设计，决定了整个过程能否做到“业务不停摆”。
动态数据里面，余额类数据的处理相对简单，比如总账科目余额、库存余额，直接取时点金额做初始化即可。但未清明细就复杂得多，比如未清采购单、未清销售订单、未清发票，不仅要迁明细，还要保证单据头和单据行的关联完整，以及单据状态在 MetaERP 里是“已审批未收货”还是“已审批部分收货”，这些状态映射必须逐条确认。
还有一个特别容易翻车的点：跨模块的数据一致性。比如一张采购单在 PO 模块是已审批状态，对应的应付发票在 AP 模块还没做匹配，那么初始化时是只迁 PO 单据，还是连带把暂估应付也迁过去？这类“业务闭环”问题，必须在动态数据初始化设计阶段就和业务确认清楚，否则上线后会出现采购单有、应付单没有的尴尬局面。
3. 数据初始化技术方案选型与映射落地
3.1 抽取工具选型：没有银弹，只有合适
技术选型这块，我见过三种主流做法。第一种是用 EBS 自带的 API 或开放表接口做数据抽取，优点是和 EBS 本身的字段语义贴合，缺点是性能一般，而且很多 API 对大批量数据支持不好。第二种是用开源 ETL 工具，比如 DataX、Kettle、Talend，优点是灵活、可控、社区生态好，缺点是需要大量脚本开发和性能调优。第三种是走自研接口服务，直接通过 WebService 或 REST API 对接 MetaERP 的导入接口，优点是和 MetaERP 的集成最顺畅，缺点是开发量大，接口稳定性完全依赖网络和中间件。
拿 DataX 举例，它在处理大批量数据抽取时性能非常可观，因为底层是并发读写的框架。我用 DataX 做过 Oracle 到 MySQL 的迁移，峰值能跑 5 万行每秒，调优手段主要是控制 channel 并发数和调整 batchSize。但 DataX 的问题是它对 Oracle 的“非标准类型”支持不够，比如 EBS 里的 INTERVAL 类型、嵌套表类型，处理起来很麻烦，通常需要先在 Oracle 侧做一次视图转换，把复杂类型转换成常规类型，再交给 DataX 抽取。
自研接口方案是最贴合 MetaERP 的，因为 MetaERP 作为新系统，它的导入接口设计通常会考虑幂等、断点续传和批量提交。我建议实际项目里采用“混合策略”：大表静态数据用 DataX 之类的批处理工具直接推，动态数据和小表用 MetaERP 的标准导入接口走 service 方式，既保证效率又保证业务校验规则不被绕过。
3.2 字段映射与代码值转换：别小看了这张映射表
字段映射是整个初始化方案里最磨人的工作，但也最不能省。EBS 的字段语义和 MetaERP 不可能完全对齐，典型的差异有几种：编码规则不同（EBS 的库存组织编码是三位数字，MetaERP 可能是五位字母）、枚举值不同（EBS 的状态码是 I、F、C，MetaERP 是 INIT、FINAL、CLOSED）、日期格式不同、精度不同（金额保留 2 位还是 4 位小数）、多语言字段处理方式不同。
我的做法是建一张“映射矩阵”，纵向是 EBS 的所有源字段，横向是 MetaERP 的目标字段，中间填充映射规则和转换脚本。这张映射矩阵不是一次性做出来的，而是靠多次预迁移的差异分析持续迭代。每跑一次预迁移，就做一次数据对比，发现哪个字段映射错了，就在映射矩阵里补一条规则。迭代三四轮之后，映射矩阵基本就稳定了。
代码值转换是细节中的细节。EBS 里一个状态字段只有几个值，看起来简单，但实际生产环境里因为历史原因，同一个字段可能存了七八种非标准值，映射脚本必须把所有值都覆盖到，不能只处理“标准情况”。我在项目里遇到过一次 AP 发票状态字段，标准值是 5 个，但实际数据里有 11 个不同的值，多出来的 6 个全是因为以前有人直接改后台数据造成的。这类问题靠开发人员猜是猜不全的，必须写 SQL 去 DISTINCT 一下，把所有历史值拉出来，再和业务确认怎么映射。
3.3 增量捕获策略：日志挖掘还是时间戳比对
增量捕获是整个数据初始化方案里技术门槛最高的部分。从 Oracle 侧往 MetaERP 同步增量，可选的路有几种：利用 Oracle 的日志挖掘（LogMiner）解析归档日志和在线日志，缺点是实现复杂、对数据库性能有影响；利用 EBS 表里的最后更新日期字段做增量比对，缺点是很多 EBS 表没有统一的更新日期字段，而且直接改后台数据不更新更新日期的情况比比皆是；利用 Oracle GoldenGate 这类第三方工具做实时同步，缺点是license 成本高，而且数据转换逻辑要另写。
我的经验是“时间戳比对 + 定期全量校验”组合拳。所有关键业务表先确保有时间戳字段（或者用审计字段代替），增量任务每 5 分钟或 15 分钟跑一次，抓取更新时间戳大于上次同步位点的数据。然后每天晚上跑一次全量对账，把 EBS 和 MetaERP 的关键表做行数和汇总金额比对，发现差异自动报警。这个方案看似笨重，但胜在简单可控，不会因为日志挖掘配置失误导致同步中断还查不出来。
这里特别提醒一件事：增量同步的脚本必须保证“幂等”。同一个单据因为更新了两次，在增量同步里被捕获了两次，如果脚本不是幂等的（比如重复插入会报主键冲突或者金额累加两次），就会导致 MetaERP 数据错乱。正确的做法是统一走 Merge 逻辑，能插就插、能改就改，对状态变更类数据要特别注意防止“旧状态覆盖新状态”的问题。
3.4 MetaERP 导入接口的适配：批量提交与错误回滚
不管前面用什么工具抽取数据，最终装载到 MetaERP 都要走它提供的导入接口或者直接表写入。MetaERP 这类新系统的标准导入接口，通常会设计一些增强功能，你必须在初始化方案里利用好。
批量提交的切片大小很关键，切太小了（比如 50 条一批）会导致导入性能极差，切太大了（比如 10000 条一批）又容易超过接口的超时设置或导致数据库锁等待。我一般是先压测几轮，从 100 开始倍增，找到最优切片。这个最优值和网络延迟、接口处理逻辑、目标表索引都有关系，没有固定答案。
错误回滚机制也是容易忽略的点。批量导入一批 1000 条，如果第 500 条报错了，前面 499 条是回滚还是保留？很多接口默认是逐条提交，失败的部分单独记录错误日志，成功后继续。但有些场景必须保证事务性，比如总账凭证的导入，凭证头和凭证行必须同生共死。这类场景走接口之前就要确认 MetaERP 的导入接口支持事务控制，不支持就得自己设计“先删后插”的补偿机制。
4. 实操过程与关键环节实现
4.1 预迁移演练：先把沙盘推演做透
正式切换之前，一定要安排至少两轮全流程预迁移演练。演练不是测试环境随便跑一遍数据就完事，而是要模拟真实切换的完整流程：选时点、停业务（或模拟停业务）、跑全量快照、执行静态迁移、执行动态迁移、做增量追赶、验证数据、切换访问。每一轮预迁移都要有独立的报告，记录耗时、数据差异、脚本报错、业务反馈，然后针对性优化。
第一轮预迁移的目标是“跑通流程”，不追求性能，哪怕静态数据迁移花了 48 小时也无所谓，先把所有环节走一遍，暴露问题和风险。第二轮预迁移的目标是“优化性能”，把全量迁移的时长压缩到真实切换窗口能接受的范围内，比如 8 小时内完成静态数据迁移，动态数据追赶在 2 小时内完成。如果两轮预演都达不了标，就得考虑并行扩容或者调整数据分层策略。
预迁移演练还有一个产出物——回退方案。真实切换时如果出了大问题，必须知道怎么回退到 EBS 继续跑业务。回退方案的核心是“前滚日志”的概念，把增量同步阶段的所有操作记录下来，一旦切换失败，可以基于这些日志做逆向操作，把 MetaERP 里初始化产生的数据清掉，重塑 EBS 的准生产环境。这块工作容易被低估，但它决定了整个项目的风险底线。
4.2 数据校验策略：不止是对数，还要看逻辑
数据校验是初始化方案里最容易“形式化”的环节。很多人觉得校验就是“两边行数一样、金额加起来一样”，但这远远不够。行数一样但内容对不上、金额相等但明细串了，这类问题靠汇总对账根本发现不了。我的经验是把校验分成三层。
第一层是完整性校验：目标表行数、关键字段非空率、主键唯一性、外键引用完整性，这些用 SQL 脚本批量跑。第二层是准确性校验：随机抽样或按关键筛选条件抽出一批单据，对比源和目标的全字段值，确认没有转换错误。第三层是业务规则校验：比如所有应付发票必须有对应的采购单（或明确的非 PO 凭证标识）、所有未清销售订单必须有客户主数据引用、库存余额必须等于所有库存事务的累计差，这类校验规则要从业务那里收集，每条都要有确认人。
另外提醒一个让人哭笑不得的坑：校验脚本本身写错了。我遇到过校验脚本把源字段写错，导致对比永远不通过，浪费了项目组整整三天时间排查，最后发现是脚本 bug 而不是数据问题。所以校验脚本上线前，一定要先在“已知差异”的数据上验证脚本的正确性——故意造一条差异数据，看脚本能不能抓到，然后再跑全量。
4.3 切换操作实录：从停业到开盘的完整流水账
真实切换当天，整个团队的工作节奏是高度紧张的。我以一次典型的“周末切换”为例，拉一条时间线出来给大家参考。周五晚上 20:00 停止 EBS 业务录入，开启只读模式，同时冻结所有接口任务。20:30 执行最终全量快照，备份 EBS 关键业务表。这个过程一般持续 1-2 小时，取决于数据量。周六凌晨 00:30 开始静态数据迁移，按物料、供应商、客户、会计科目、成本中心的顺序执行。静态数据预计 6-8 小时完成。
周六上午 10:00 左右开始动态数据迁移，先迁未清采购单、未清销售订单、未清发票，再迁库存余额和总账余额，每个模块之间有依赖的先决顺序。下午 14:00 启动增量追赶，把快照之后到停业之前的新增变化同步到 MetaERP，目标是 2 小时内追赶完成。下午 16:00 开始数据校验，三层校验并行执行。晚上 20:00 校验全部通过，切换业务访问到 MetaERP 的准生产环境，供指定用户做 UAT 冒烟测试。
周日白天做 UAT 测试，业务人员按测试脚本跑核心流程，晚上 22:00 正式开盘，全员切换到 MetaERP 作业。周一早晨的早高峰就是真正的考验——并发数一上来，性能问题会集中暴露。切换的成功不只是“数据搬过去了”，还在于后续三天没有严重的业务阻塞。
4.4 上线后的跟踪期：前两周盯紧这五张表
数据初始化的工作不是切换完就结束了，上线后的跟踪期内，我最关注五类数据：EBS 侧的新增数据是否还有人绕过流程直接录入（这时 EBS 应该已经彻底封存或设为只读）；MetaERP 侧的异常主数据数量（比如因为映射错误产生的重复档案）；接口同步的失败任务数量；未清项的账龄分布是否合理（如果初始化后出现大量“超过 90 天未清”的异常单据，说明初始化规则有问题）；库存台账和财务账之间的差异额。
跟踪期的数据健康度检查和切换前的预迁移校验不是一回事。前者是统计意义上的“差不多”，后者是逐笔核对“分毫不差”。上线之后要建立的是持续的数据质量监控体系，把异常数据扼杀在萌芽状态。我见过有些项目上线一个月后发现应收模块对不上账，追查下来是初始化时一张映射错误导致几百张发票的状态全乱了，这种问题越晚发现代价越大。
跟踪期还特别要留意“初始化遗留问题”的闭环。切换时因为时间紧迫，有些数据问题可能是暂时绕过或手动修复的，但这些“临时方案”必须在跟踪期内转正——要么补脚本、要么补数据、要么补流程，不能一直靠人工兜底。
5. 常见问题与排查技巧实录
5.1 数据一致性校验失败的四大类原因
第一类是映射规则错误。表现是预迁移时校验报告里某个字段大量不一致，比如成本中心的编码全部错位、或者会计科目的“段值”拼接规则不对。排查方法很直接：抽一条数据对比源和目标，就能定位到映射规则的问题。这种问题最怕的不是报错，而是“看起来对、实际上错”，比如编码长度恰好一样，但含义完全不同。
第二类是历史脏数据导致的目标表违反约束。表现是导入时报主键冲突、唯一索引冲突或外键缺失。排查思路是先按约束类型分类，再从源数据里定位“惹事”的数据。比如物料主数据的唯一性冲突，往往是源系统里本身就有两条编码不同但税号相同的记录，MetaERP 的唯一索引更严格,导致无法插入。这类问题的解决不是改 MetaERP 的约束，而是要回到源数据里做合并治理。
第三类是动态数据的时点差问题。表现是余额数据对得上，但明细单据对不上，或者反过来。根本原因是快照的时点不统一，某个模块的快照在 8 点取，另一个模块的快照在 9 点取，中间 1 小时发生的新单据没有完整纳入快照。解决办法是设计统一的“快照协调机制”，所有模块都要在同一个全局时间点冻结。
第四类是编码体系不一致。表现是最麻烦的一种，因为出错后不会立刻暴露。比如供应商编码在 EBS 用的是内部生成的编号，但 MetaERP 要求用税号或统社会信用代码做唯一标识，初始化时要么做编码映射，要么直接把税号作为主键。如果映射表维护不完整，就会出现同一供应商在不同单据里被对应到不同 MetaERP 编码的“一对多”问题。这是项目里最消耗精力的一类问题。
5.2 增量同步中断的排查路径
增量同步中断是最常见的运行时问题，原因逃不出三类：网络抖动导致连接断开、源端数据异常导致 SQL 解析失败、目标端约束冲突导致批量导入终止。排查路径我建议按“三查”走：查日志（同步组件有没有报错堆栈）、查位点（增量同步的位点表有没有推进）、查数据（最近一批目标表有没有新增数据）。
最容易让人忽略的是“同步位点丢失”的问题。增量同步任务重启时，如果位点是从内存里取的，而不是从数据库位点表里取的，一旦进程异常退出，位点就可能回溯或丢失，导致重复同步或跳数。解决的办法是位点持久化，每成功同步一批就更新位点表。我做过一个项目，就是因为位点保存在本地文件里，任务漂移到另一台机器后位点丢失，结果重复同步了几十万条数据，目标端出现大量主键冲突，团队花了一个晚上才清理干净。
增量同步期间千万不要用手工方式直接改目标表数据，哪怕发现了错误也别改。我见过有人为了让某条数据“看起来对”直接 update 目标表，结果增量任务再次同步时把原有数据覆盖了，造成了更大的混乱。正确做法是让增量任务停下来，改源端数据或改转换脚本，重新跑增量。
5.3 性能瓶颈：大数据量迁移跑不动的三大诱因
第一个诱因是源端查询性能差。EBS 里有些表几十亿行，不加任何过滤条件全表扫描，再好的数据库也扛不住。解决思路是分批抽取，按分区键、主键范围、时间范围切片，每片几百万行，逐片拉取。千万别想着“一次性 select 出来”，那只是小数据量的做法，大数据量必须分片。
第二个诱因是目标端写入性能差。MetaERP 的目标表如果索引建得太多、太复杂，大批量插入时每次都要更新索引，性能会急剧下降。实测下来，一次插入 100 万行到有 8 个索引的表，比插入到只有 3 个索引的表要慢 4-5 倍。所以初始化期间有条件的，建议先禁用或删除部分非关键索引，数据装载完成后再重建。
第三个诱因是网络吞吐成为瓶颈。Oracle 和 MetaERP 如果在不同机房，数据抽取和写入都要经过网络，带宽不够时百万行级别的数据传输会非常痛苦。我在项目里遇到过因为防火墙限速，明明源端和目标端都很快，但整体迁移速度就是上不去的案例。经验是先做一次小规模压测，比如抽 10 万行数据测实际吞吐，再估算全量数据量的理论耗时，提前发现网络瓶颈。
5.4 切换后业务反馈的“数据看不到”问题
上线后最常听到业务的一句话是：“这单在 EBS 里明明是有的，为什么 MetaERP 里看不到？”这类问题八成不是数据真的丢了，而是查询条件没对上。比如 MetaERP 默认只查“最近 90 天”的单据，历史数据虽然在库里，但被默认条件过滤了。排查思路是先确认业务用的查询条件，再反过来验证数据是否在库。
还有一种可能是权限问题。MetaERP 的数据权限模型和 EBS 不一样，业务用户可能只有部分法人、部分库存组织的数据权限，老数据因为所属组织编码映射错误，跑到了用户无权查看的组织下面。这类问题隐蔽性很高，用户看到的是“部分单据缺失”，实际上是权限过滤。排查方法是找一个缺少单据的用户，用管理员权限查同一条主数据，如果管理员能看到，那问题就定位在权限配置上。
切换后的第一周，业务反馈的问题大量集中在“数据查询不到”“状态显示不对”“某字段为空”这三类。每个问题都要记下来归因——是初始化本身就缺了，还是转换规则错了，还是权限问题，还是用户操作习惯问题。归因清楚才能快速给出对策，不能一上来就重跑数据，那是下下策。
写在最后：一点实操体会
替别人操盘过几次大型 ERP 替换，又在生产环境里给 MetaERP 和 EBS 这类系统做过数据底座的人，都清楚一个道理：数据初始化做得好的项目，后面无论功能怎么迭代、流程怎么调整，都不会出大乱子；数据初始化做得糙的项目，上线后很长时间都会在“补账、对账、修数据”的泥潭里挣扎。
我个人最大的体会是：别把数据初始化当成一个“搬砖任务”，它本质上是一次对企业数据资产的最彻底盘点。EBS 里沉睡多年的重复档案、错误代码、失效主数据，平时没人会去动它们，是数据初始化逼着所有人正面面对。这个过程虽然痛苦，但做完之后，你的数据治理水平一定会上一个台阶。
还有一个小技巧分享给大家：初始化过程中，把所有决策和规则都沉淀成文档，而不是散落在聊天记录和会议纪要里。一个映射规则的确认，可能是业务、财务、IT 开了三次会才敲定的，如果只是口头确认，后面反悔了也无据可查。每个字段、每条规则、每个异常处理，都应该有责任人、有确认时间、有版本号。
数据初始化的活儿很细、很碎、很磨人，但它就是这个替换项目的承重墙。墙打得牢，后续才有资格谈业务价值；墙打歪了，后面再光鲜的解决方案也补不回来。希望这篇梳理能对正在做或准备做类似工作的人有一点帮助。
