When legacy system integration beats replacing the core

Before choosing an integration tool, decide whether the legacy system is wrong or merely hard to reach

An ERP that still calculates orders, inventory and customer flags correctly does not need replacement just because its data is available only through a decade-old screen. That is an integration problem: the system remains a trustworthy source, but modern software cannot reach its answers cleanly. A system whose order-state logic no longer matches operations, or whose unit-of-measure field means different things depending on who populated it, has a different problem. Its underlying behavior can no longer support safe change.

Establish that difference before choosing an API facade, change data capture (CDC) or an integration platform as a service (iPaaS). First write down whether the problem is an inability to expose trustworthy information or an inability to change a system whose logic or model has become invalid. Enterprise software programs still have to balance legacy constraints with new architecture and compliance requirements, but those constraints do not automatically justify rewriting correct business logic.

Integration audits commonly find the first condition, and practitioners behind these patterns describe most ERPs as fitting it. Modernization vendors also benefit commercially when an organization concludes that replacement is necessary, giving them an incentive to blur the distinction. Neither claim changes the architectural test. If the old system gives the right answer, isolate how other software reaches or interprets it; if the answer itself is increasingly wrong, another interface cannot repair the underlying behavior.

A cheap connection can preserve the coupling you meant to remove

The distinction becomes concrete with direct database access because it can solve connectivity within hours while preserving nearly all the architectural risk. A developer opens a connection to the ERP database, queries the order table and ships the new service. There is no facade to build, broker to operate or versioned contract to define, so the initial implementation can look unusually efficient. The cost has simply been deferred until the first incompatible database change.

That change creates schema drift, which means the database structure or the meaning of its data changes underneath consumers. A renamed column, repurposed status code or retired foreign key can break every service that depends directly on the table, with no interface version and potentially no warning. The ERP’s internal representation then becomes a supported interface even though nobody agreed to support it. The people who designed that schema often no longer own it.

The effects show up in ERP and core-system integration reviews. In one engagement, half a dozen services queried the same order table while applying different undocumented interpretations to the same status code. Across such reviews, legacy order states, customer flags and unit-of-measure concepts repeatedly appeared unchanged in modern services. Each team had independently inherited the old system’s assumptions and built its own interpretation of them.

That accumulated coupling can be acceptable for a temporary reporting query against a system already scheduled for retirement, where downstream stability has no long-term value. Outside that narrow case, the low initial operating cost is deceptive because a schema change can turn deferred maintenance risk directly into an outage. Avoiding that outcome requires a deliberate boundary. The right boundary depends on what needs to be isolated.

Choose the boundary according to what must be isolated

When the old system already has the right answer and its interface is the obstacle, an API facade creates a controlled contract. The facade is a separately owned thin service that translates the legacy interface into a form modern applications can consume, without requiring those applications to understand the old schema or changes to the legacy code. For an ERP whose useful data sits behind decades-old structures, that can provide enough isolation. Integration practitioners describe most ERPs as fitting this broad “cannot expose” condition.

Because the facade owns translation, its job differs from an API gateway’s. The gateway handles traffic concerns such as routing, authentication, rate limiting and request logging across one or more backends. The facade protects consumers from the legacy interface by translating its representation. Putting raw ERP endpoints behind a gateway may improve traffic management, but consumers remain coupled to the ERP’s representations.

That translation makes the facade a moderate build: one service, one team and a defined contract. Its continuing cost appears when the ERP schema changes and somebody must update the translation, particularly after the engineers who built it have moved elsewhere. More importantly, a facade becomes too thin when legacy concepts still emerge unchanged in modern code. At that point, the boundary has to isolate a domain model as well as an interface.

An anti-corruption layer provides that stronger boundary by translating legacy concepts into the domain model used by new software. Martin Fowler describes it as “a layer that translates between two domain models so that changes on one side do not leak into the other.” A legacy system can be correctly designed for its original purpose and still need this layer because its model differs from the one appropriate for the new services. Translation therefore does not by itself show that the legacy core is wrong.

ERP fields make that model mismatch visible. Cryptic order states, customer flags and unit-of-measure fields can contain long-lived business rules that modern applications should not each have to decode. During code review, an unchanged legacy field name or status code in a new service is a strong warning, especially when reviewers need someone to explain its meaning. When several consumers perform that decoding independently, each becomes responsible for understanding the legacy model.

Because the anti-corruption layer centralizes that interpretation, building it requires translation classes, mapping tests and an explicit home for logic that was previously implicit in an old schema. The extra work localizes later changes: if an ERP vendor renames a status value or adds another one, the translation can change once instead of forcing every consuming service to change. The key boundary lies between translating a valid legacy model and repeatedly correcting behavior that has become invalid. Repeated correction moves the problem toward modernization.

Different access requirements call for an asynchronous boundary. CDC and event streaming fit when consumers need changes continuously or repeated polling would put excessive load on the legacy application. CDC reads the database transaction log and converts row changes into events without altering application code. A broker or queue can then distribute those events to multiple services, preventing each consumer from creating another query path into the old system.

That distribution mechanism follows a property Gregor Hohpe and Bobby Woolf describe in Enterprise Integration: producers and consumers are decoupled through intermediary channels. In practice, new services can consume a change without directly querying the ERP. The same work provides historical context for the Enterprise Service Bus (ESB), a centralized integration pattern that promised a common path for system-to-system traffic but could itself become an unwanted legacy system. Centralizing integration changes where coupling is managed, but lifecycle concerns remain.

Those lifecycle concerns shape the CDC implementation. The build is described as moderate: a transaction-log connector, an event schema and contract tests able to expose schema drift. Operating it requires broker infrastructure, consumer-lag monitoring and schema-evolution management, with effort growing as the consumer population grows rather than simply with endpoint count. AWS guidance on event-driven architecture is particularly relevant to ordering and delivery guarantees because those semantics can create implementation problems that a synchronous call does not have. AWS sells cloud infrastructure and event-driven services, so it has a commercial interest in organizations adopting architectures that use those capabilities.

Delivery infrastructure also cannot establish whether an event still has the correct business meaning. If a source column is renamed or repurposed, a connector can remain apparently healthy while emitting incorrect data until a consumer detects the semantic change. Contract tests matter because infrastructure health cannot prove that downstream software still interprets an event correctly. For one consumer that simply needs a synchronous answer, a facade is usually simpler and cheaper; where the database provides no usable transaction log, a scheduled batch export is the appropriate fallback rather than describing periodic extraction as streaming.

Beyond those one-to-one and one-to-many boundaries, scale changes the economics again when many independently shaped systems must exchange information. Practitioner guidance puts the iPaaS threshold at roughly a dozen systems spanning different formats, schedules and protocols. With only the first two systems communicating, a facade or CDC pipeline is cheaper to build and operate. At around a dozen systems, custom point-to-point work can approach n² connections, each with its own failure behavior.

An ERP, CRM, warehouse management system and several SaaS applications exchanging data on different cadences are the kind of estate where iPaaS can earn its licence. The platform can centralize integrations that would otherwise be individually engineered across a growing set of systems. In return, the organization becomes dependent on proprietary connectors and transformations embedded in platform-specific DSLs, meaning domain-specific languages used to define those transformations. Licensing can also rise as endpoints are added.

That dependence repeats a lesson from the ESB experience. Enterprise Integration’s historical treatment of the pattern shows why a central integration layer can acquire enough embedded behavior and organizational dependence to become another system that is difficult to change. Modern iPaaS products can reproduce that lifecycle problem through different technology. The deciding question remains what the boundary isolates: interfaces, models, query load and multi-system coordination are integration concerns, while a boundary increasingly responsible for making incorrect core behavior correct is taking on modernization work.

Compare lifecycle cost with implementation cost

Once the boundary is chosen, its implementation estimate captures only part of the cost. Integration consumes compute and licences, but it also consumes specialized human knowledge about why mappings, retries and event handling behave as they do. An option that minimizes the initial project can become expensive after years of schema changes, endpoint growth and staff turnover. Direct database hooks and simple facades show the pattern clearly because their deferred maintenance can become an outage when the legacy schema changes.

iPaaS moves more of that lifecycle cost into a visible recurring bill. Two pricing patterns matter in observed ERP-heavy estates: platforms can price around connectors and data volume rather than the complexity actually solved, and licensing can scale with connector or endpoint count rather than transaction usage. These patterns expose the planning problem even though pricing models vary. Per-connector costs have repeatedly risen on observed ERP estates after the underlying integration work stopped materially changing.

The fifth connected system illustrates why the charging unit matters. Its licence impact can increase whether it moves ten records per day or ten million, and integration budgets have been observed creeping upward simply as endpoint counts increased without materially greater data flow. The platform’s economic unit can therefore differ from what the business perceives as useful activity. Architecture reviews need to include that recurring relationship when comparing implementation estimates.

Recurring human knowledge creates another operating dependency. Integration layers require automation infrastructure and process redesign, then often survive longer than the teams that created them. Five years later, current staff may be unable to explain a retry rule or why an event stream removes duplicate order-state messages. Technical debt has a precise meaning here: a system that people cannot safely modify, regardless of whether its code looks tidy.

A wrapper stays temporary only when ownership, tests, and an exit are explicit

Because human knowledge can disappear, an integration layer needs explicit lifecycle controls from the start. The risk becomes concrete when a layer has no owner, no tests against the system it wraps and no documented condition for retirement. With all three missing, a temporary bridge can become another legacy system while still carrying a temporary label. The boundary receives changes from both sides, so its maintainability is an operating requirement.

Tests provide the first control by checking assumptions against the legacy system itself. ERP modules get patched, status codes are renamed and vendor upgrades add order states, so tests confined to new services cannot detect every relevant change. A test suite tied to anti-corruption mappings can detect that drift when it occurs. Without that check, the first clear evidence can be a silent production mismatch that reaches customers.

Ownership addresses a different lifecycle failure. The integration layer should have a named owner distinct from both the legacy-system owner and the new-platform owner, because responsibility for the boundary can otherwise fall between those teams. ERP and core-system reviews have found ownerless layers outliving the engineers who understood how they failed. Once that knowledge disappears, ordinary maintenance itself becomes risky.

Retirement controls the other end of the lifecycle and belongs in the design document rather than a backlog item with no forcing condition. Useful conditions are concrete: “Tear down when the ERP migration completes” and “tear down when consumers read from the event stream directly”. A boundary with no such event has effectively been designed with an indefinite lifetime, whatever the project originally called it. Fowler’s strangler fig pattern does not by itself supply a removal condition for integration infrastructure whose retirement was never defined.

Those controls become more important as the boundary gains independence. A warning appears when it acquires its own release cycle, separates operationally from both connected systems and gains mapping logic quarter after quarter. Facades deliberately create interface contracts, anti-corruption layers deliberately isolate models, and CDC deliberately creates event contracts, so contract testing, explicit ownership and retirement conditions keep those contracts changeable. If those controls weaken while behavior accumulates, the wrapper starts to acquire the same maintainability problem it was supposed to contain.

When the boundary starts replacing the core, reopen modernization

That maintainability problem changes the architectural decision when the underlying issue shifts from exposing trustworthy information to safely changing the system itself. One signal is an anti-corruption layer whose translation rules grow faster than the business logic underneath it, leaving the organization maintaining two evolving models. Another is organizational: current engineers understand wrapper failure modes but can no longer explain the core system because its original ownership and knowledge have disappeared. Isolation then becomes the default consequence of lost understanding rather than a controlled architectural choice.

Security can independently move the decision because an unsupported core changes the risk of every surrounding boundary. If the legacy vendor has stopped issuing patches, each additional integration point can increase exposure around an unpatched core. Economics can do the same when wrapper operations, on-call work, contract-test maintenance and an iPaaS licence together exceed the cost of replatforming amortized over three years. These are practical heuristics rather than universal financial thresholds, especially when a broader enterprise software program also has architecture and compliance requirements to satisfy.

Those signals matter more when they accumulate. Practitioners treat any one of them as manageable and “Two or more together” as the trigger for reopening modernization. At that point, another integration pattern is unlikely to address the changed problem. The wrapper may have started as a legitimate way to preserve correct logic, but accumulating mappings, vanished ownership, unsupported software or unfavorable run economics can change the decision later.

Once that decision changes, one modernization option is the strangler fig pattern, which Martin Fowler named in 2004. It replaces capabilities incrementally while the original platform remains operational, cutting each capability over after the replacement has been proven. That makes it a modernization strategy even though integration boundaries may be involved during the transition. Once wrapping no longer pays, the 7 Rs framework is also suggested as a starting point for the modernization discussion; for ecommerce systems, a legacy ecommerce modernization guide is referenced for strategy, roadmap and risk trade-offs.

Key highlights

• Test whether the core still gives the right answer: Architecture teams can separate access problems from modernization problems by checking whether legacy business logic remains trustworthy. Correct logic supports integration; increasingly invalid behavior makes replacement more credible.
• Treat direct database access as long-term coupling: Direct queries reduce initial build effort but expose every consumer to schema drift and undocumented legacy assumptions. Use them primarily for short-lived cases where downstream stability has little long-term value.
• Match the integration boundary to the problem: Use API facades for interface isolation, anti-corruption layers for domain-model translation, CDC for continuous change distribution, and iPaaS for larger multi-system estates. Reassess the approach when the boundary starts correcting core behavior.
• Compare lifecycle economics: Technology leaders can evaluate integration options using recurring licences, operations, specialist knowledge, schema maintenance, and outage exposure alongside implementation cost. Endpoint-based iPaaS pricing and staff turnover can materially change the economics over time.
• Give every wrapper ownership and an exit: Assign a named owner, test mappings against the legacy system, and define a concrete retirement condition when the boundary is created. These controls keep temporary integration infrastructure from becoming another difficult legacy system.
• Reopen modernization when warning signs accumulate: Rapidly growing translation logic, lost core-system knowledge, unsupported software, and unfavorable operating economics indicate that isolation is losing value. Multiple signals together justify reassessing incremental replacement or another modernization path.