01
代码状态能否运行、部署、修复问题，是否有文档和负责人
越改越乱，任何小需求都可能引发新问题
判断摘要
旧系统能不能改，先看风险，不要只看界面旧不旧
旧系统是否重做，关键不在界面是否老，而在代码是否可维护、数据是否清楚、业务是否还适配、迁移风险是否可控。很多项目适合分阶段替换。
02
数据迁移用户、订单、客户、财务等核心数据能清洗和映射
新系统上线后历史数据无法使用
03
替换节奏按模块、角色或业务线逐步切换，降低停机风险
一次性重做影响正常经营
风险地图
把风险写在开发前，而不是上线后才发现
下面这些点会直接影响预算、周期、验收和后续维护，适合放进方案、报价单或合同确认项。
01
代码状态要提前确认
能否运行、部署、修复问题，是否有文档和负责人。如果这一项没有写清，常见风险是：越改越乱，任何小需求都可能引发新问题。
- 把“代码状态”写进需求、报价、合同或验收清单。
- 确认双方对“代码状态”的理解一致，不只停留在口头沟通。
- 如果涉及费用、账号、数据、上线或维护，建议形成可交接记录。
02
数据迁移要提前确认
用户、订单、客户、财务等核心数据能清洗和映射。如果这一项没有写清，常见风险是：新系统上线后历史数据无法使用。
- 把“数据迁移”写进需求、报价、合同或验收清单。
- 确认双方对“数据迁移”的理解一致，不只停留在口头沟通。
- 如果涉及费用、账号、数据、上线或维护，建议形成可交接记录。
03
替换节奏要提前确认
按模块、角色或业务线逐步切换，降低停机风险。如果这一项没有写清，常见风险是：一次性重做影响正常经营。
- 把“替换节奏”写进需求、报价、合同或验收清单。
- 确认双方对“替换节奏”的理解一致，不只停留在口头沟通。
- 如果涉及费用、账号、数据、上线或维护，建议形成可交接记录。
核对清单
旧系统评估建议检查这 7 项
这些资料不用一次写成完整文档，但越早补齐，需求评估、报价和验收边界就越清楚。
下一步
还没写需求文档，先回答这 4 个问题
如果这 4 个问题还说不清，建议先别急着定开发价格，先把业务闭环和交付边界整理出来。
Ready
咨询技术顾问需要按你的项目具体判断？
把业务场景、预算范围、上线时间和已有资料简单发来，月弦科技会先帮你判断首版范围、报价边界和后续维护重点。