很多企业一决定重构老 ERP，第一反应就是先讨论顺序：数据库先重做，接口先服务化，还是权限先重构。
这三个方向听起来都对，所以项目一开始很容易开很多会。问题是，顺序一旦判断错，团队就会很快陷入另一种忙碌：底层改了不少，业务还是照样救火；规范做了很多，真正最失控的那一层却没先止血。
我自己的判断是，这不是一个“谁更底层谁先上”的问题，而是一个“哪一层已经在持续制造业务事故”的问题。
多数情况下，先收接口边界更稳
如果老 ERP 现在还在跑，最现实的约束通常不是技术，而是业务不能停。
这时候直接大动数据库，往往会把报表、同步脚本、外围系统、历史数据兼容一起卷进去。表面看是在治根，实际上很容易先把影响范围放大。尤其是老系统跑久了之后，很多调用关系根本不在文档里，而是在脚本、人工流程和各种历史补丁里。
所以多数情况下，我会更建议先收接口边界。先把几个最关键的问题定住：
-
哪些动作允许被外部系统调用
-
哪些字段可以写，哪些只能读
-
哪些状态流转必须经过明确流程
-
哪些高风险操作必须留痕
这样做的好处是，哪怕数据库暂时还没有彻底重整，系统至少先有了边界。很多原来被默认放行的脏写入、重复改状态、脚本直连数据库，都会在这一步先暴露出来。
对交付来说，这一步更像止血。它不一定最底层，但通常最适合先把混乱圈住。
数据库该先动的情况，通常是接口层已经兜不住了
当然也不是所有项目都该先动接口。
如果核心数据本身已经失真，比如同一个业务对象有多套主键、多套状态定义，跨表关系长期对不上，甚至同一份订单在不同模块里都不是同一个意思，那接口层再怎么包，也只是把脏地基包得更复杂。
这种情况下，数据库就该前置。但我还是不建议一上来就喊“全库重构”。
更实际的做法，通常是围绕一条主链路先收小范围地基。比如先把订单主表、明细、状态流转、库存占用这几个最容易传导错误的点理顺。先把一条链跑稳，比一次性推翻全部底层更接近可交付。
我见过不少项目的问题不是“不够现代”，而是业务事实已经对不齐。这时候数据库先动，不是为了架构好看，而是为了让系统重新有可信的数据主线。
权限不一定最先大改，但绝对不能最后才想起
老 ERP 里还有一层经常被低估，就是权限。
很多系统表面上看是有角色、有菜单、有按钮控制的，但真正关键的状态修改、字段写入、审批绕行，最后还是能被少数人或者少数脚本轻易改掉。结果就是前面刚把接口和数据理顺，后面又被越权操作重新打乱。
所以我的经验是，权限不一定要第一阶段就做成一套大而全的独立工程，但它必须从第一阶段就成为约束条件。
至少要先回答清楚几件事：
-
哪些角色能改关键状态
-
哪些字段必须审批后才能写
-
哪些动作必须留下明确审计记录
-
哪些默认管理员权限其实应该被收回
权限如果只留到后面“再统一做”，前面的重构成果通常很难稳住。
一个更实际的排顺序方法
如果一定要把这件事说得更落地一点，我一般会先看三件事：
第一，看现在最失控的是不是写操作入口。如果是，就先收接口边界。
第二，看核心数据口径是不是已经烂到接口层也兜不住。如果是，就把数据库相关主链路前置。
第三，看越权操作是不是已经在持续破坏流程。如果是，权限必须立刻进入第一阶段约束，而不是留到最后补。
真正稳的重构，通常不是一上来就把三层一起翻掉，而是先选最会出事故的那一层止血，再让另外两层配合推进。
老 ERP 重构最怕的，不是技术债多，而是每一层都觉得自己最重要，最后项目同时开三条大战线，结果哪条都收不住。
