旧系统历史数据迁移，先确定唯一写入方和可回退边界

先选择与业务连续要求匹配的迁移路线

先按业务对象确定迁移范围，不从复制数据表开始

旧库中的表结构是历史实现，不等于新系统的业务边界。迁移计划应先回答哪些客户、订单、库存、合同、审批、附件和审计记录必须在新系统继续使用，哪些只需要依法留存查询，哪些已确认可以停止使用。

为每类对象标明权威来源、业务主键、时间范围、数据负责人、保留规则和目标用途。一个订单可能分散在主表、明细、支付、退款、物流和附件中；只搬主表会得到数量正确但无法履约的半成品。小程序、APP、管理后台、外部接口和 AI 智能体如果会读取这些对象，也要列入依赖清单，确认切换后访问的是同一份权威状态。

对字段建立映射表，记录来源、目标、类型、枚举转换、时区、空值、默认值和舍弃理由。历史脏数据不要在迁移脚本中悄悄“修好”，应输出异常清单，由业务负责人决定修正、保留原值还是隔离。个人信息与商业敏感数据只迁移业务所需范围，测试演练使用受控或脱敏副本。

• 用业务对象和使用场景定义完成范围，而不是用“所有表已导入”代替。
• 把主键、外键、附件、字典、序列和审计记录分别列入清单。
• 对每项删除、合并和字段转换保留依据、负责人及可追溯记录。

把全量迁移做成可重复、可暂停和可审计的基线任务

第一次全量迁移的目标是建立可复测基线，不是直接在正式切换夜临时执行。脚本应在固定快照或明确水位上读取，按稳定主键分批处理，并记录每批输入范围、目标结果、耗时、失败原因和重试状态。

迁移逻辑与普通导入不同：它需要幂等。重复运行同一批数据时，应更新同一目标对象或明确拒绝冲突，不能生成第二个客户、订单或流水。对编码、精度、时区、排序规则和大字段做样例验证；目标系统的约束、触发器和默认值可能改变结果，应在正式工具与目标版本上演练。

先测出全量导出、传输、转换、导入、建索引和校验各自耗时，再决定是否需要提前加载。运行期间观察源库查询压力、目标库写入与存储压力，设置暂停条件；校验任务同样会消耗源端、目标端与网络资源，不能默认与生产高峰并行不会影响业务。

• 固定代码版本、配置、数据水位和执行账号，使同一次结果可以重现。
• 分批记录成功、失败、跳过与人工待定项，重跑不会重复产生业务对象。
• 用接近真实规模的数据演练迁移和校验，并记录资源影响与预计窗口。

全量之后继续捕获新增、修改与删除

只要旧系统仍在写入，全量完成就只是一个时间点。后续增量可以来自数据库变更捕获、业务事件、更新时间扫描或受控导出，但必须证明它能识别新增、修改和删除，并能从中断位置继续。

为增量保存不回退的水位或日志位置，以及源事件标识、目标处理状态和最后错误。基于更新时间扫描时，要处理时钟、同一时间戳多条记录、事务提交延迟和历史代码不更新该字段等问题；基于 CDC 时，要核对所用数据库与工具对表、DDL、序列、大对象和主键的限制。PostgreSQL 官方文档明确说明逻辑复制通常先复制快照再发送后续变化，同时列出 DDL、序列与大对象等限制，这些能力不能靠想象补齐。

双写不是默认答案。应用向新旧系统各写一次时，任意一次超时都可能让两边状态分叉；若确需双写，应指定写入主责、稳定业务标识、重试与补偿方式，并持续对账。更容易控制的路线通常是保留单一写入方，再通过日志或事件把变化投递到另一侧；最终仍要按项目能力验证。

• 记录增量起点、当前位置、延迟、失败队列和可安全重放方式。
• 明确更新、删除、关联变化、附件和非表对象各自如何同步。
• 同一业务对象只设一个权威写入方，冲突进入可审计处理流程。

按业务结果对账，不只比较总行数

行数和逐行字段比较能发现部分错误，但不能证明订单可履约、库存可用、余额相等或权限正确。验收应同时包含技术校验、业务汇总和代表性流程回放。

技术层按表或对象核对总数、空值、唯一性、关联完整性、哈希或字段差异；业务层按组织、日期、状态和币种等维度核对订单金额、退款、库存、应收与审批结果。抽样应覆盖历史边界、异常状态、大附件、已删除关联和特殊客户规则，不只看最近的正常数据。

AWS DMS 官方资料说明其校验可在全量后比较源目标记录，也能对持续变更进行复核，同时提醒校验查询会增加源端、目标端和网络负载。无论是否使用该工具，都应保存校验范围、时间水位、通过项、差异项和排除规则。允许差异必须逐项有业务依据，不能用一个宽松比例掩盖金额、库存或权限错误。

• 数据数量、字段与关联完整性形成机器可重复校验。
• 金额、库存、状态、权限和关键报表由业务负责人按同一口径确认。
• 每个差异有对象标识、原因、处置方式、复核结果和批准记录。

把正式切换写成按分钟执行的运行手册

切换手册至少包含参与人、入口控制、写入冻结或路由、最终增量、序列与配置检查、业务冒烟、对账、放量、停止条件和决策人。每一步都应有开始条件、完成证据和超时后的动作。

先在演练环境走完同一顺序，确认脚本权限、执行时间和联系人真实可用。正式窗口开始后，阻止未纳入同步的旧入口继续写入；等待在途事务完成，记录最终水位，执行最后增量和关键对账，再把小程序、APP、后台、接口及定时任务切到新系统。缓存、搜索索引、消息消费者和文件链接也要核对，避免数据库正确但用户仍看到旧状态。

AWS 的切换指导将写入冻结、最终备份、数据同步、路由与验证列为关键阶段，并要求预先定义触发回退的检查点和决策责任。是否可以分批放量取决于入口能否路由以及新旧系统是否能安全共享数据；不能保证时，应使用经过演练的维护窗口，而不是为了宣称不停机引入不可控双写。

• 切换前确认监控、告警、客服通知和业务负责人均已就位。
• 切换中记录每一步时间、水位、执行结果与继续或停止决定。
• 放量后同时观察错误、增量延迟、业务对账与外部接口处理结果。

回退前先回答新系统已经产生的数据去哪里

如果新系统尚未接收写入，回退可能只是恢复旧入口；一旦新系统产生订单、审批、库存或余额变化，旧系统就已过时，直接切回会造成业务数据丢失或重复处理。

在发布前定义两类恢复路径：切换前或只读阶段可以恢复旧入口；产生新写入后，应按对象决定反向同步、导出补录、暂停业务后合并，还是修复前进。为每条路径明确最大可接受数据缺口、人工工作、验证步骤和决定人，并用脱敏样例演练。备份只有在实际恢复并完成业务核对后，才算可用。

保留旧系统时要限制写入权限，避免回退准备期仍有人从隐蔽入口改数据。迁移完成后不要立即删除旧库、映射表和日志；按合同、合规与业务查询需要设定只读保留和退役计划。本文不承诺零停机，也不提供所有数据库通用的复制配置，实际路线应根据源目标产品、版本、数据规模、业务窗口和团队运维能力确定。

• 回退条件同时包含技术失败与关键业务对账失败。
• 新系统写入的保存、反向同步或人工补录路径已经演练。
• 最终签收后再按保留规则关闭同步、收紧访问并安排旧系统退役。

需求讨论中的问题

关联服务与实施资料

下面的页面可继续核对相关技术边界、业务接入方式与项目交付条件。

• 生产数据库结构变更指南：区分跨系统数据迁移与同一生产库的兼容结构发布。
• 小程序与 APP 一体化开发：核对多端入口、后台与数据权威来源的整体边界。
• AI Agent 智能体开发：让智能体通过受控接口读取已确认的业务数据与权限。
• 软件项目启动资料包：补充需求、交付物和验收清单，便于迁移项目询价与交接。