Bespoke systems · JNAGA perspective
Should you integrate existing systems or replace one of them?
When work crosses several tools, a new system can look like the cleanest answer. Sometimes the boundary between tools is the real problem.
Published 25 September 2026
Find the authoritative record
Identify which system is trusted for each important fact and who corrects it when it is wrong. If nobody owns the record, connecting systems may distribute conflicting information more efficiently. A replacement will not solve that by itself either.
Trace one real case through the tools. Note manual re-entry, delays, missing context and decisions made outside the software. This reveals whether the difficulty lies in the tools, the integration or the operating model.
Compare the whole lifecycle
Integration can preserve useful investments and reduce disruption, but introduces interfaces that need monitoring when either side changes. Replacement can simplify some workflows, but migration, training and temporary parallel operation are substantial work. Compare those ongoing responsibilities, not just the initial build estimate.
A partial change may be enough: a clearer service layer, one well-owned integration or a better way to handle exceptions.
Choose a reversible first step
Before committing to a full replacement, test a representative workflow and the information it needs. Record what would make the integration approach fail and what would justify a broader change. The decision should follow evidence about real use, not a preference for a single platform.
Imagine a customer record is sound in one system, but staff copy its status into another each afternoon. A replacement project would move a large body of stable work to solve one fragile handover.
Test whether a well-owned integration and a clear rule for conflicting statuses can repair that boundary. Replace the system only if the wider process genuinely cannot be served by it.