SYSTEMS NOTE / INTEGRATION
An old or awkward system can still contain essential rules, data and dependencies. Before rewriting everything, identify which part of the work needs a new layer.
An ERP may look like an outdated interface, but it often contains years of data, rules, exports, operating habits and links to accounting, inventory or production.
Replacing it means migrating those dependencies as well. The cost is not simply building a new UI.
If the problem lives before, after or between multiple tools, an operating layer can unify views, collect data, orchestrate activities and send the ERP only what should remain authoritative there.
The existing system keeps its role while day-to-day work changes.
Before promising an integration, APIs, import/export formats, databases, webhooks, permissions and licensing limits need to be verified. Where no reliable integration point exists, that constraint should be explicit.
A fragile automation that simulates clicks may be acceptable for a prototype, but it should not silently become critical infrastructure.
There are cases where a rewrite is correct: unsupported technology, no viable integration path, security constraints or unsustainable operating costs.
That decision should come after mapping the existing system. The principle stays simple: preserve what works, build what is missing.
Before replacing an ERP, separate what is old from what is still authoritative.