Every implementation starts with an inventory of what the client already runs. And almost every implementation has the same reflex when it hits a system the new platform overlaps with: replace it. One platform, one login, one source of truth — the consolidation story is clean, and it sells.
It is also, frequently, the wrong call. The system that should survive the engagement is often the one nobody on the project wants to touch — because the people who depend on it chose it, trust it, and are fluent in it. The real architecture decision is not how fast can we migrate off. It is where do we draw the integration boundary.
The cost of a forced migration is mostly invisible at proposal time
When you propose replacing a working system, the costs that show up in the estimate are the obvious ones: data migration, configuration, testing. The costs that don't show up are the ones that decide whether the project is remembered as a success.
A team that has spent years inside a tool has built fluency that is not in any document. They know its quirks, its shortcuts, the report that's slightly wrong and how to read around it. Replacing the tool resets all of that to zero. For the duration of the relearning curve, the team is slower, more error-prone, and — this is the part that compounds — quietly resentful of the project that made them slower at their own job.
If the system being replaced is one the team chose — a PLM the engineers picked, a design tool, a specialist piece of software for their trade — the resentment is sharper. You have not just changed their tool. You have overruled their judgment.
The test: is this system the source of truth for something, and does it work?
We keep a system — and integrate rather than replace — when two things are true.
It is the authoritative source of truth for a domain. Engineering BOMs and change orders live in PLM. That is what PLM is for. A general-purpose ERP can hold a manufacturing BOM, but it is not where engineering thinks. If a domain has a system built specifically for it, and the client's experts work in that system, that system is the source of truth for that domain. Fighting that is fighting the org chart.
It works. Not "it's fine." It works — the people who use it are productive in it and it is not the thing causing the problem the engagement was hired to solve. A working specialist system plus a clean integration beats a single platform that does everything adequately and nothing the way the specialists need.
When both are true, the platform we build consumes that system's data across a defined boundary. The specialist system stays the source of truth; our platform is a faithful, current consumer of it.
Drawing the boundary
An integration boundary is a contract. Designing it well is most of the work.
Name the source of truth per field, not per system. The boundary is cleanest when every field has exactly one owner. The engineering BOM is owned upstream; the manufacturing routing is owned in our platform. Ambiguity here — two systems both think they own the same field — is how integrations rot into nightly reconciliation calls.
Move meaning, not just data. A field-for-field copy is not an integration. The upstream system speaks in its own model; the consuming system needs the data in the shape its workflows actually use. The integration's job is the translation — projecting an engineering BOM into a manufacturing BOM with routings and effectivity, not echoing a table.
Decide what happens when the boundary is unavailable. Integrations fail — networks, credentials, upstream downtime. The boundary needs a defined behaviour for that: queue and retry, fail closed, serve last-known-good with a staleness marker. An integration with no failure design is a future outage with a date not yet assigned.
Make change propagation explicit. When the upstream system releases a change, the consuming side should receive it with the right effectivity — not have it appear mid-process as a surprise. "The BOM changed and nobody downstream knew" is a class of defect that good boundary design eliminates structurally.
When replacement IS the right call
This is not an argument against ever replacing a system. Replace when the system is the source of the problem — when it is the bottleneck, the data-integrity risk, the thing that cannot scale. Replace when it is abandonware with no support and no path forward. Replace when "integrating" it would cost more than rebuilding it and the rebuild is genuinely better.
The point is narrower: replacement should be a decision, made against these tests — not a reflex triggered by the consolidation story being easy to tell.
The note for the file
The strongest version of "we built you a modern operating system" is not "we replaced everything." It is "we replaced what was holding you back, integrated what was working, and your team kept the tools they were already good at." That is a harder story to put on a slide. It is a much better system to operate.