Separate a workflow gap from a system problem.
An ERP can be sound at its core job and still leave a team with a difficult manual process. A missing approval screen, a slow label workflow, or a disconnected customer portal does not automatically justify replacing the entire system.
Describe the problem without naming a product. Identify what the user needs to do, which data they need, and where the existing system falls short. That keeps the conversation about the work rather than a preference for a particular technology.
Check the interfaces before committing.
Review the APIs, supported imports and exports, vendor restrictions, authentication options, and deployment constraints. An available endpoint may still lack the field or operation the workflow requires. Confirm those details against representative data.
Prefer supported interfaces and documented ownership. Direct database writes or brittle screen automation can create maintenance and upgrade problems. If those are the only options, make the dependency and failure risks explicit before treating an extension as the easy route.
Include the operating cost.
Compare more than the initial build. An extension needs monitoring, updates, access management, and support. A replacement needs data migration, training, cutover planning, and a way to reconcile the new system with the old one.
Ask who will operate each option after the project team leaves. A smaller initial project may be more valuable when it gives the business a maintainable improvement, but an extension that depends on an unsupported legacy system may only defer a necessary change.
Build a small, observable connection.
If the extension path is viable, begin with one useful transaction and one clearly defined outcome. Document the field mapping, event ownership, duplicate behavior, and what happens when either system is unavailable.
Plan visibility from the beginning. Operators need a useful failure state, and support needs enough information to identify a failed event without exposing unnecessary customer or business data in logs.
Know when replacement earns its scope.
Replacement becomes a stronger candidate when the core system cannot support required controls, no longer receives appropriate support, or cannot represent essential business processes. Those are different problems from a missing interface.
NIST’s Cybersecurity Framework 2.0 organizes security outcomes across governing, identifying, protecting, detecting, responding, and recovering. Use those categories as prompts when assessing either option; an integration should not quietly bypass controls the core system depends on.
Further reading: NIST Cybersecurity Framework 2.0. This field note offers general planning guidance; the scope and controls of a project depend on the operation.