3. 迁移目标与范围定义：别急着动手，先画好地图
做审计系统迁移，最容易犯的错就是一上来就动手干。我见过太多团队，代码库拷过来就开始适配，结果搞到一半发现——哎？这个模块根本不在迁移范围内，那个老系统接口文档早过期了。
说白了，迁移升级这件事，80%的坑都出在“没想清楚要迁什么”这个阶段。这一章我们就来聊聊怎么定义迁移目标和范围。这可是整个项目的地基，地基歪了，后面全白搭。
3.1 定义迁移目标：你到底图什么？
先问自己一个问题：为什么非要迁？
是真的跑不动了？还是硬件要淘汰了？或者只是为了“跟上技术潮流”？
我个人的习惯是，把目标分成三类来梳理：
- 业务目标——提升审计流程效率？支持更多并发用户？缩短报表生成时间？
- 技术目标——数据库版本升级？中间件替换？操作系统去CentOS化？
- 合规目标——满足等保2.0要求？通过第三方审计？数据加密标准升级？
记住一点：目标要可量化。“系统性能提升”这种话太虚了，不如写成“单次审计报表生成时间从5分钟缩短到30秒以内”。
小技巧：我一般会用SMART原则来卡目标。具体、可衡量、可实现、相关、有时限——每一条写出来，含糊的统统打回去重新写。
3.2 业务域与系统清单：给老系统做个体检
目标定好了，接下来就是梳理资产。这一步做不好，后面有你好受的。
我曾经接手过一个项目，客户说“就三个子系统”，结果一查——光数据库就有7个实例，还有4个没人维护的遗留服务挂在生产环境里。你想想看，这种烂摊子不清干净，迁移后怎么收场？
怎么梳理？我建议按这个顺序来：
- 业务域拆分——审计计划、审计执行、审计报告、问题跟踪、知识库，每个域是一个独立模块。
- 系统盘点——列出每个域对应的服务、数据库、中间件、前端应用。
- 依赖关系梳理——谁调了谁？数据流怎么走的？同步还是异步？
这一步的产出最好是一张表格：
| 业务域 | 应用服务 | 数据库 | 中间件 | 外部依赖 |
|---|---|---|---|---|
| 审计计划 | plan-service | MySQL 5.7 | Redis + RabbitMQ | HR系统（LDAP） |
| 审计执行 | exec-service, workflow-engine | Oracle 11g | WebLogic | OA系统（SOAP接口） |
| 审计报告 | report-service, report-web | SQL Server 2012 | IIS + .NET Framework 4.5 | 文档系统（NAS挂载） |
嗯，这一步很枯燥，但逃不掉。我习惯用Excel或者Notion来维护，后续所有决策都基于这张表展开。
警告：千万不要遗漏存量数据中的“暗依赖”，比如某个定时任务脚本硬编码了数据库IP，或者某个报表服务直接连接了生产库。这些都得翻出来。
3.3 技术栈盘点与版本确认
系统清单列完了，接下来要深入看技术栈。为什么要看这个？因为版本号决定了你的迁移路径。
举个栗子：老系统用的是JDK 1.6，你想直接升级到JDK 17？那改动量可能跟重写差不多。中间差着4个LTS版本，API改了多少你心里没数吗？
我建议用这个模板来盘点技术栈：
服务名称: plan-service
编程语言: Java 1.6 → 目标 Java 11
框架: Spring 3.2 → Spring Boot 2.7
数据库: MySQL 5.7 → MySQL 8.0
中间件: Tomcat 7 → Tomcat 9
操作系统: CentOS 6 → Rocky Linux 8
容器化: 无 → Docker + K8s
这里有个关键动作：确认版本兼容性。比如Spring 3.x到Spring Boot 2.x，配置方式完全变了，XML配置要改成Java Config。Oracle 11g到Oracle 19c，plsql的某些写法也要调整。
硬核经验：我前期吃过一次亏——迁移方案做得漂漂亮亮，结果中间件版本不兼容，服务启动报了一大堆ClassNotFoundException。后来我养成了一个习惯，所有版本组合都要在测试环境验证一遍，不验证的不动。
3.4 迁移策略选型：一刀切还是分步走？
范围清楚了，技术栈摸透了，接下来就是选策略。常见的就三种：
- 大爆炸迁移——一个周末全部切换。风险高，但周期短。
- 分批迁移——按模块或按业务域分批次切。风险可控，但周期拉长。
- 并行运行——新旧系统同时跑，慢慢切流量。最安全，但成本翻倍。
怎么选？我个人的判断标准是：
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 系统耦合度高，改动量小 | 大爆炸 | 越快越不容易出问题 |
| 模块独立，可解耦 | 分批迁移 | 每个批次回退成本低 |
| 业务连续性要求极高 | 并行运行 | 出了问题立刻切回旧系统 |
| 团队经验不足 | 分批或并行 | 降低单次操作风险 |
说白了，没有银弹。你必须根据自己团队的能力、系统的耦合程度、业务方给的窗口时间来权衡。我遇到过最无语的情况是领导拍脑袋说要“大爆炸”，结果一个晚上没搞定，周一业务直接停摆...嗯，你懂的，那锅最后是谁背。
3.5 本章核心逻辑图
到这里，我们把迁移目标和范围定义的核心流程理清楚了。下面这张SVG图可以帮你快速回顾整个逻辑链路：
这张图要表达的核心就是：先定目标、再摸家底、最后选策略，顺序不能乱。每一步的产出都直接影响下一步，少一个环节，后面的执行就瘸一条腿。