In a legacy ERP refactor, should database, APIs, or permissions come first?

If the legacy ERP is still running, the usual constraint is that the business cannot stop. A direct database overhaul often drags in every integration point, report, sync script, and downstream tool at once. That blast radius is hard to control. In contrast, tightening the API layer first makes it easier to define which actions are allowed externally, which fields are writable, and which state changes must go through explicit workflows, all without forcing a full stop on operations.

Once API boundaries are clearer, many hidden problems reveal themselves. You can see which data should never have been edited from multiple places, which business logic is hiding in frontend code or scripts, and which fields survive only because of historical baggage. In that sense, the API layer is often the best place to stop the bleeding first. It is not the deepest layer, but it is often the fastest way to contain chaos.

There are real exceptions. Some ERP databases are not merely ugly; they have unstable keys, conflicting duplicate fields, broken status definitions, and no reliable backbone for the same business object across tables. In that situation, wrapping more APIs around the system is mostly painting over a dirty foundation. If the underlying business truth is inconsistent, the API layer quickly becomes a more elaborate compromise instead of a cleaner boundary.

Even then, a full database rewrite is rarely the safest first move. A steadier option is to rebuild the core data model around one main chain first, such as orders, order lines, state transitions, and inventory reservation. Stabilizing that slice of the foundation is usually much more deliverable than declaring a total database reconstruction from day one.

Permissions are one of the most underestimated problems in legacy ERP systems. Many products appear to have roles, but critical actions are really controlled by hidden buttons, vague admin defaults, or habits people developed outside the intended process. The danger is that if permission refactoring becomes a giant RBAC project too early, the team can get trapped in abstraction and still fail to stop immediate operational damage.

A more practical approach is to treat permissions as a hard constraint from the first stage of the refactor. Define which roles can change critical states, which fields require approval, and which actions must always leave an audit trail. In other words, permissions may not need to be rebuilt first as a standalone module, but they should shape API and data decisions from the beginning. Otherwise the refactor cleans one side of the system while uncontrolled actions break it again from the other side.