一、迁移前先盘家底：哪些数据必须带走，哪些可以归档
迁移前先盘清楚数据家底，常见的迁移范围有五类：订单数据（含支付流水、退票记录）、会员数据（含积分、等级）、年卡季卡数据（含剩余次数和有效期）、财务数据（对账单、发票记录）、渠道对账数据（各OTA和分销渠道的订单与结算记录）。每一类都要明确迁到新系统的哪个模块，别等导完了才发现落了个模块，这一步错了后面全跟着错。
不是所有数据都值得迁：早已过期的历史订单、多年未活跃的会员、已核销完的票务明细，可以只迁汇总数据或直接归档。行业里一般按近3年全量加更早数据归档的原则处理，既保住运营所需，又不让无用数据拖慢迁移。归档数据要能查，别一封了之，否则历史对账时翻不出来更麻烦。
盘点结果要形成数据清单：每类数据的表名、字段、数据量、负责人，写清楚后和供应商逐项确认新系统的承接方式。盘点越细，后面清洗、转换、验证阶段返工越少。盘点过程中发现旧系统字段含义不明的地方，趁旧系统的老员工还在，第一时间问清楚。
二、迁移五步走：盘点、清洗、转换、导入、验证
迁移按五步走。第一步盘点：列出所有数据表、字段、数据量，和供应商确认新系统的字段对应关系；第二步清洗：处理脏数据、重复数据、格式不一致的数据，具体规则下一节展开；第三步转换：把旧系统的数据格式转换成新系统能识别的格式，票种编码、渠道编码这类映射关系要提前建好映射表，以双方书面确认为准。
第四步导入：先在测试环境导入一遍，跑通流程、核对数据，再在正式环境导入。导入要分批进行，订单、会员、年卡按模块分批次，每批导入后立即验证，别一次性全量灌进去。每批导入前先做数据量预估，给足执行时间，避免半夜导入到一半超时中断。
第五步验证：按验证清单逐项核对，全部通过才切换上线。五步里最容易被压缩的是清洗和测试环境导入，恰恰这两步最省不得。省掉的功夫，都会在上线后的对账和客诉里加倍找回来，迁移节奏宁可放慢，也别赌运气。
三、脏数据不清，迁过去就是新系统的定时炸弹
脏数据是迁移事故的头号来源，常见三类：一是重复数据，同一订单或同一会员在旧系统里有多条记录；二是残缺数据，缺手机号、缺支付流水号、金额对不上；三是历史遗留数据，早已失效的票种、已废弃的渠道编码、测试数据混在正式数据里。先给脏数据分门别类，再定处理规则，分类清单先给业务方确认一遍再动手。
清洗要有明确的处理规则：重复数据按保留最新、合并关联处理；残缺数据能补则补、补不了就标记隔离，别让脏数据混进正式库；测试数据单独删除。清洗结果要出报告，每类数据处理了多少条、怎么处理的，写清楚留档，迁移后有问题能溯源。
清洗的时机也有讲究：迁移启动前一到两周就开始清洗，别等导入当天边导边洗。清洗过程中旧系统还在产生新数据，要和业务方约定一个数据冻结时点，比如切换前一天的营业结束后，把冻结时点之后的增量数据一并处理进去，避免两边数据对不上。
四、新旧系统并行期怎么安排最稳妥
新旧系统并行是降低风险的标准做法，一般并行1-4周。并行期内两套系统同时运行：新系统先承接新增订单，旧系统保留只读查询，供查历史订单和报表。游客端只看到新系统，员工端新旧系统都要能访问，别把查历史数据的入口提前关掉。员工培训也要跟上，别让人不会用新系统。
并行期最怕两边数据不一致：同一订单在新系统退了款，旧系统还显示正常。解决办法是并行期内以新系统为唯一业务入口，旧系统只读不写，退款、改签等操作全部在新系统完成。每天定时比对两边订单数量，差异出现当天就查，别攒到月底。
并行期要有明确的结束条件：新增订单在新系统连续稳定运行一定天数、历史数据查询无异常、对账无误，才正式下线旧系统。行业里一般以连续两周无异常作为切换参考。并行期也别无限拉长，两套系统同时维护的成本和出错概率都会上升，该收就收。
五、验证清单：订单数、金额、会员数逐项对账
验证的核心是对账，三个数必须对上：订单总数、订单总金额、会员总数。分别拿旧系统迁移前的数据和新系统迁移后的数据逐项比对，差额为零才算通过。金额要对到分，订单数要对到笔，会员数要按总量和活跃量分别核对。对账时建议导出明细逐行比对，别只信汇总数，汇总对上了再看分类，两层都过才算数。
除了总数，还要抽查明细：随机抽取一定比例的订单，核对票种、渠道、支付方式、状态是否一致；年卡要核对剩余次数和有效期；退款记录要核对退款金额和状态。抽样的比例行业里一般不低于总量的1%-2%，金额大的订单建议全查。
最后验证业务功能：用迁移后的会员数据试跑购票、退票、年卡续费全流程，确认数据在新系统里真的能用，而不只是看起来在。数据迁过去不能用，比没迁更麻烦。功能验证要覆盖线上购票、窗口售票、闸机验票三个入口，各跑一遍才放心，验票异常要当场排查、记录在案。
| 验证项 | 验证方法 | 通过标准 |
|---|---|---|
| 订单总数 | 迁移前后订单总量比对 | 数量一致，差额为零 |
| 订单金额 | 迁移前后订单总金额比对 | 金额精确到分一致 |
| 会员数据 | 会员总量与活跃量分别核对 | 总量一致，活跃量差异在容忍范围 |
| 年卡数据 | 抽查剩余次数与有效期 | 逐张核对无错漏 |
| 退款记录 | 退款金额与状态抽样核对 | 状态和金额完全一致 |
| 业务功能 | 迁移后试跑购票/退票/续费 | 全流程跑通无报错 |
六、迁移事故高发在哪，怎么提前防住
迁移事故高发的四个环节：一是字段映射错误，旧系统票种编码和新系统对不上，导致票种错乱；二是金额精度问题，分和元换算出错，对账不平；三是导入顺序错误，先导订单后导会员，关联数据缺失；四是验证走过场，只对数不清点，上线后才发现问题，这四类占迁移返工的大头。
预防办法对应四条：映射表建好后先做小样本试导，验证映射无误再全量导入；金额统一按分存储或明确精度规则，导入后做总额校验；导入顺序按基础数据（票种、渠道、会员）到业务数据（订单、退款）执行；验证环节设立独立复核人，数据对账和业务抽测由不同的人做，避免自己验自己。四道防线一起上，事故率能降一大截。
迁移全程要有回滚预案：正式导入前保留旧系统的全量备份和迁移日志，出问题能恢复到迁移前的状态。备份不能只做一份，本地和异地各留一份，并且要验证备份真的能恢复。回滚预案要写清楚触发条件和执行步骤，别等出事了才现翻文档。
常见问题 FAQ
数据迁移一般要多久？
看数据量和清洗难度。中小景区订单和会员数据量不大，快的一两天能完成迁移和验证；数据量大、历史遗留问题多的，加上清洗和并行期观察，一般2-4周。别追求快，验证环节宁可多花几天。
迁移期间景区还能正常售票吗？
能。迁移一般在夜间低峰或闭园后进行，白天业务照常。并行期内新系统承接新增业务，旧系统只读查询，游客端无感知。关键是迁移前和供应商约定好时间窗口，避开节假日和活动大促期。
旧系统里的数据格式和新系统对不上怎么办？
这是常态，靠转换环节解决：先建字段映射表，把旧系统的票种、渠道、状态编码映射到新系统的对应编码，再做小样本试导验证，最后全量导入。映射表建得越细，后面返工越少。
会员积分和年卡剩余次数会丢吗？
只要纳入迁移范围就不会丢，但需要逐项核对。年卡按剩余次数和有效期迁移，积分按余额迁移，迁移后抽查验证。建议迁移前让会员数据冻结一个晚上，避免迁移过程中产生新变动导致对不上。
迁移完发现数据有问题还能回滚吗？
可以，前提是迁移前做了完整备份和回滚预案。正式导入前保留旧系统的全量备份和迁移日志，发现问题时按预案恢复到迁移前状态，重跑迁移流程。所以迁移前一定确认备份完整可恢复，这一步不能省。