为什么整体重写很少是简单重启
整体重写看似提供干净基础，却必须重新发现多年积累的规则、例外和用户习惯；旧系统在新系统开发期间也会继续变化。
主要风险包括业务连续性、数据迁移、用户采用，以及新系统能否真正支持实际运营。
- 未记录的业务规则
- 历史数据
- 遗留集成
- 意外用户行为
- 过渡期间差异扩大
先建立系统全景图
在选择策略前，理解组件、数据流、依赖、故障点和最常变化的区域。
将技术地图与业务连接：每个组件支撑什么流程、由谁使用、故障会中断什么工作。
- 模块与职责
- 数据库
- 系统集成
- 定时任务
- 用户入口
- 监控与备份
先稳定，再转型
当事故不可见时，团队无法有把握地现代化。第一阶段可以增加可观测性、关键流程测试、已验证备份和可重复部署。
这些变化可能不改变界面，却能降低之后每一步的风险。
在脆弱区域周围建立清晰边界
大型单体系统可以逐步隔离职责。API、适配器和队列能够降低直接依赖。
目标不是追求服务数量，而是让局部变化无需理解或部署整个系统。
有效边界应对应明确业务责任，而不是追随架构潮流。
按用户路径、能力或业务域逐步替换
过渡可以围绕一条完整用户路径、一个业务能力或一个数据域展开。每个阶段都应带来可观察价值并具备回退方案。
逐步迁移流量或用户群，方便在全面切换前比较结果并纠正问题。
- 受控双写
- 共享读取来源
- 分组迁移
- 成功标准
- 回退计划
把数据迁移当作一个产品
数据不是上线前最后搬动的文件，它有质量、历史、规则和负责人。
应准备数据画像、可重复转换、核对机制，以及对不完整或矛盾记录的明确处理方式。
- 盘点与分类
- 清洗
- 标识符映射
- 迁移演练
- 切换后核对
不要只衡量删除了多少代码
成功可能表现为事故减少、部署更安全、规则修改更快、关键路径性能改善或人工工作下降。
这些指标把技术投入与组织变化能力连接起来。
- 部署频率与安全性
- 问题解决时间
- 关键路径覆盖
- 变更成本
- 用户体验
选择组织能够持续执行的过渡方式
即使技术策略优雅，如果组织无法同时运营两个系统、验证数据或支持用户变化，项目仍可能失败。
计划必须符合预算、运营周期、现有知识和可接受风险窗口。