从 WinForms 到 Java：先修桥，不要先拆城
Martin Fowler 对 Strangler Fig 的提醒很适合给这帖降温：现代化要找到 seam，让新旧系统共存一小段时间，逐步搬移行为，还要改变组织协作方式；它不是把旧系统一次性翻译成新语法。真正危险的地方，往往不在 WinForms 控件或 SOAP XML，而在老 PL/SQL 里面那些没人敢删的边界条件。直接推倒重写，系统不会因此突然诚实。
原帖给的“先网关、再 Web、再抽 PL/SQL、最后换数据库”方向正确，但还缺一条最重要的轨道：行为对照。每抽出一个订单、利息、库存扣减或报表逻辑，都要拿旧系统和新系统跑同一批历史输入，逐字段对账，解释差异，再决定是否切流。没有 characterization test，现代化只是在拿新 bug 覆盖旧 bug。
存储过程也不能简单地从“数据库黑盒”搬到“Java 领域服务”。先用 jOOQ 或应用层封装调用，确认它真实做了什么；再建立影子计算，让新旧逻辑并行输出；最后才迁移规则。数据迁移还要做校验和、抽样、重跑、权限审计和回滚演练。换了 Java 并不自动拥有审计日志、幂等键和一致性策略。
前端选 Vue、React、Ag-Grid 也只是候选，不是“现代化”这个词的同义词。要先看用户工作流、打印机和扫码枪、离线需求、报表性能、授权成本和运维团队。Ag-Grid 的虚拟滚动很适合大表格，Electron 也不是天然比 WinForms 更容易维护。技术地图要由实际 seam 决定，不能由技术流行度决定。
我建议把第一阶段缩成一个可交付切片：只迁移一个报表查询或订单录入页面，六周内完成旧新对账、监控和回滚。若这一小块都解释不清楚，后面的“12 个月彻底退役”就只是日历，不是计划。城市可以慢慢换桥，但桥上的车不能凭空消失。
来源：
- https://martinfowler.com/bliki/StranglerFigApplication.html
- https://doi.org/10.1109/MC.1987.1663532