本文将教你为WordPress迁移制定正式切换记录：明确停写窗口、核对新增订单、控制新旧站访问，并在故障时保护已经产生的数据。这里假定迁移副本已经完成隔离测试，不再比较插件或压缩包容量。核心问题是：哪一台站点有权接收写入，切换后新增的数据由谁负责保存？
把切换前提写成可以验收的条件
WordPress（开源内容管理系统）的页面能够预览，不代表它已具备接管业务的条件。切换前确认目标的程序版本、数据库模式、证书、登录、计划任务和第三方依赖都已验证。不要在搬主机的同一窗口顺便升级主要插件、切换订单存储模式或重做域名结构，否则出现问题时难以区分原因。
指定一名切换负责人，并明确业务确认人、数据核对人和主机支持联系人。HostEase或其他服务商可以协助哪些环节，需提前按当前支持范围确认；他们能够修改解析，不等于会自动核对全部商城订单。开始前记录允许的维护时间、成功条件、停止条件以及谁有权决定回退。
- 目标站演练已通过，原始备份有独立副本且实际恢复过。
- 新旧站配置和数据版本有记录，目标没有不应覆盖的独有业务数据。
- 支付、邮件、库存和外部回调的负责人与处理方式已确认。
- 回退步骤明确保护新增数据，不能只有一句“出问题改回DNS”。
停写范围比维护页面更大
维护页面通常只控制部分前台请求。后台编辑、REST接口、XML-RPC、计划任务、队列任务、库存同步和支付回调仍可能修改数据库。应按实际插件和集成逐项盘点写入入口，选择经过演练的控制方式，并通过日志或业务记录确认写入确实进入受控状态。不能把“页面显示维护中”当作停写证据。
特别处理仍在途的支付与订单
停止新结账后，仍可能收到此前订单的支付通知。与支付服务和应用维护人员确认重试、暂存及恢复处理机制，记录待处理的事务标识；不要简单丢弃回调，也不要在未持久化处理的情况下返回成功而让对方停止重试。恢复处理时需利用现有业务的幂等机制，避免重复扣款、重复发货或重复扣库存。
全库只读可能影响会话、任务和必要状态更新，并不是所有站点都能直接采用的通用方案。使用数据库层控制时，必须先在对应架构中验证其影响和恢复方法。无论选择哪种方式，都要让团队知道当前唯一有效的写入目标。
最终同步后核对数据，而不是只看文件完成
初次迁移与最终停写之间，旧站仍可能产生订单、用户、评论和上传。最终同步应覆盖实际发生变化的数据，并保留开始与结束时间。文件同步成功不能证明数据库一致，数据库导出成功也不能证明关联文件已齐全。按数据库备份策略选择与引擎、负载和应用一致性相符的方法。
商城核对要覆盖关联状态
核对约定时间窗口内的订单标识、金额币种、支付状态、退款、库存变化、客户关系及待处理任务。总订单数相同不代表每条内容相同，最高订单号也不能证明没有缺口。记录差异清单，先查明原因再开放目标写入，不能凭少量首页抽查代替业务核对。
WooCommerce可能使用传统文章表存储或HPOS（高性能订单存储），实际权威数据源取决于配置与版本。插件还可能使用自定义表。参照WooCommerce官方HPOS说明核对当前模式，不要假定只复制一张订单表就完成迁移，也不要把存储模式切换当作修复搬站差异的捷径。
DNS传播期间持续防止双写
DNS（域名解析系统）的TTL表示缓存有效期，但既有缓存、客户端行为和代理连接会影响实际切换过程。提前降低TTL并不能让已经缓存的旧记录立即失效。修改解析后，要从多个实际使用网络观察目标，并结合新旧站访问日志确认流量去向，不能只检查自己的电脑。
旧站保留受控状态，防止残留访问创建另一套独立订单；新站在最终核对通过后成为唯一写入目标。若架构采用代理或转发，也必须提前验证身份认证、请求体、支付通知及故障回退，不能临时拼接一个未经测试的转发规则。对未被覆盖的旧入口，应有明确维护提示和后续处理方式。
切换期间保留原有安全防护和受限管理入口。不要为了让测试方便就公开源站或共享管理员密码。证书有效、页面可访问、接口正常与数据一致性是不同验收项，分别记录结果。
回退要区分新站是否已经接收写入
| 当前状态 | 回退前先确认 | 不可省略的动作 |
|---|---|---|
| 新站尚未接收业务写入 | 旧站数据是否仍完整且未被覆盖 | 按预案恢复旧入口，确认唯一写入端并继续监测 |
| 新站已有订单或其他变更 | 新增数据范围与关联状态 | 冻结进一步变化，保护新站快照和记录，评估前向修复或受控数据回迁 |
| 新旧站均出现独立写入 | 冲突订单、库存、支付和任务的归属 | 暂停相关写入，由熟悉应用的人逐项核对并制定合并方案 |
新站已经产生订单时，不能用旧备份整库覆盖，也不能盲目把新表追加到旧表。标识冲突、外键或业务关联、库存及支付状态都可能导致错误。应由应用负责人使用适合当前版本和插件的数据处理方式，先在副本验证再执行；不存在适用于所有商城的一条通用SQL合并命令。
有时在新站修复一个已定位的配置问题，比跨环境回迁新增数据更可控。选择前向修复还是回退，应依据影响范围、数据保护和预案，而不是只看哪一个按钮更快。恢复演练可参考备份恢复演练指南。
恢复营业前后分别验证
隔离演练使用测试数据
演练副本需限制访问，禁用真实邮件、计划任务和外部回调，支付使用沙箱配置。用测试账号验证登录、购物车、结账、订单状态和后台查询，避免演练产生真实扣款或发货。不要把测试环境的配置误带回生产。
正式环境做受控验收
开放写入前检查生产依赖配置与授权状态；开放后优先观察真实业务的只读指标和已授权监测。若确需真实支付验证，应由业务负责人明确安排并核对后续退款、库存和通知，不默认执行。确认订单只写入一处、待处理回调被正确消化、队列不重复运行，才算恢复营业。
可用云服务器（按需提供计算资源的服务）上线检查清单补齐基础设施验收，资产范围参照网站迁移资产清单。WordPress的路径与配置处理以官方迁移手册为依据，不把商城业务核对简化为文件搬运。
建议你在结束记录中写明最终写入目标、数据核对结果、临时措施、旧站保留期限与后续负责人。确认回退不再需要旧环境后，再按保留政策处理备份、撤销临时权限并退订相关主机，避免过早删除仍有用的证据和数据。