搬迁核心业务系统不是搬服务器这么简单，它关系到整个企业的命脉。我见过太多人把这件事想得太轻松，结果上线当晚就出问题，第二天业务直接停摆。要想平稳落地，必须把整个过程拆解清楚，每一环都不能出错。
搬迁前先做完整评估和规划
很多人一上来就问用什么工具、怎么迁移数据，但最关键的其实是评估。你得先搞清楚当前系统里有哪些模块、依赖哪些中间件、数据量有多大、哪些是实时交易、哪些是批处理任务。没有这份清单，后面越走越乱。
我建议你先拉一个全量资产清单，包括服务器IP、数据库实例、应用版本、配置文件、定时任务、网络策略，甚至那些没人记得但还在跑的脚本。这一步很苦，但躲不掉。然后根据业务影响度给每个系统定级，核心交易系统必须优先保障，辅助系统可以分批走。
规划阶段的另一个重点是回退方案。不是"万一失败怎么办"，而是"怎么在最短时间内切回去"。你要准备好回退脚本、回滚数据、切换网络，并且要真正演练一遍。我在项目里见过最坑的事就是回退方案只停留在PPT上，真出事了没人知道怎么操作。
搬迁执行要分阶段并做好验证
搬迁不能一口气全搬完，必须分批次。我一般建议分三到四轮：第一批放非核心系统，第二批放读多写少的业务，第三批才动核心交易系统。每一批之间留够观察期，至少一个完整的业务周期，比如一周。
重点着重讲一下数据迁移这一方面。数据一致性在其中是最大的陷阱，尤其是对于那些涉及实时交易的系统而言。在进行数据迁移时，你能够运用增量同步工具，不过务必要在搬迁之前开展全量对账工作，在搬迁完成之后还得再进行一次全量对账。千万不要盲目相信工具自动校验得出的结果，人工抽检是绝对不可或缺的。我曾经亲身经历过一次由于字符集问题而致使数据错乱的事故，当时工具显示一切正常，然而实际上中文全部变成了乱码。
就拿数据迁移来说，它存在诸多需要特别留意的地方。特别是在涉及实时交易的系统中，数据一致性所带来的风险尤为突出。使用增量同步工具虽可行，但全量对账工作在搬迁前后都不能忽视。不能单纯依赖工具自动校验的结果，人工抽检的环节必须落实到位。像我遭遇的那次字符集问题引发的数据错乱事故，工具给出没问题的结论，可实际情况却是中文都成了乱码，这充分说明了人工抽检的重要性。
验证环节不能只看系统是否启动，要看业务能否跑通。你要准备好测试案例，覆盖正常交易、异常交易、边界场景、批量跑批。最好让业务人员也参与进来，他们最清楚哪笔交易是常态、哪种报错是致命的。别光让开发测，开发和业务对"可用"的理解往往不一样。