Building the Bridge from Legacy to Modern
Getting data from a legacy system to a modern one is harder than it sounds — and easier to get wrong than most programs acknowledge. Here is how the integration was designed, and what it reveals about the soul of Strategic EA.
Series: The Living Data — Part 3 of 3
"The patterns are designed. The architecture is approved. Now comes the hardest part: connecting the legacy system to the modern one without degrading either. This article examines the integration strategy that made the Customer 360 architecture work — and closes with the three principles that determine whether any architecture actually delivers business value."
In Parts 1 and 2 of this series, we established why the Customer 360 architecture needed to be built, and how the two patterns at its center — Event-Driven Architecture and CQRS — were chosen to resolve specific, named concerns. Both parts dealt primarily with the design logic.
This part deals with what sits between the design and the outcome: the integration strategy that connects the legacy system to the modern architecture, and the governance and philosophy that determine whether that connection delivers lasting value or simply creates a faster version of the same problems.
THE INTEGRATION CHALLENGE: CONNECTING TWO WORLDS
The EDA and CQRS architecture described in Part 2 depends on one precondition: events must flow from the legacy system of record to the event bus that distributes them to downstream consumers. That flow sounds straightforward. In practice, it is one of the most technically and organizationally demanding aspects of any modernization program.
The core tension is this. The legacy ERP carries the primary transaction workload of the organization — financial processing, order management, inventory control. It was not designed to be a real-time event publisher. Any integration approach that places additional computational load on the ERP risks degrading the performance of the very system the organization depends on to run.
The architectural principle that governed the integration design was what practitioners describe as zero-impact integration: extracting data from the legacy system in a way that the system itself does not feel.
WHAT IS DATA LINEAGE — AND WHY DOES IT MATTER?
Data lineage is the documented history of how a piece of data moves through an organization — where it originated, what transformations it underwent, and where it ended up. It is the answer to the question: if this number on this dashboard is wrong, where did the error enter the system?
In a simple architecture, lineage is obvious. Data lives in one place. If it is wrong, the source of the error is straightforward to identify. In a distributed architecture — where data moves from a legacy ERP through an integration layer, is transformed into business language, published as an event, and stored in a read model on a cloud platform — lineage becomes a governance requirement, not a documentation exercise.
Without lineage documentation, a data quality problem in the Customer 360 dashboard becomes an investigation that touches multiple systems, multiple teams, and multiple transformation steps. With lineage documentation, the same investigation has a map.
The business value of data lineage is often invisible until it is needed — at which point its absence is extremely visible.
ZERO-IMPACT INTEGRATION: HOW DATA LEAVES THE LEGACY SYSTEM
Two approaches were evaluated for extracting events from the legacy ERP without degrading its performance.
The first was Change Data Capture — a technique that monitors the database transaction log directly, detecting changes at the storage level rather than through application-layer queries. Because it reads from the log rather than querying the application, it places no computational load on the ERP itself. Every committed transaction is automatically captured and forwarded to the event bus. The ERP is unaware that the capture is happening.
The second was a controlled API layer — a set of defined service interfaces through which external systems could request data from the ERP, with strict rate limiting applied to ensure that external query volume could never consume more than a defined percentage of the system's available capacity. This approach gave the integration team more control over the structure and semantics of the data being extracted, at the cost of slightly higher latency than direct log capture.
The choice between the two depended on the specific characteristics of each data domain being extracted — the transaction volume, the sensitivity of the data, the tolerance for latency, and the complexity of the transformation required. Some domains used Change Data Capture. Others used the controlled API layer. Both were designed to the same governing principle: the legacy system must remain stable throughout the integration, and its performance characteristics must not change as a result of the modernization work happening around it.
DATA SEMANTICS: TRANSLATING TECHNICAL LANGUAGE INTO BUSINESS LANGUAGE
The second integration challenge was more subtle than performance — and arguably more consequential for the long-term value of the architecture.
Legacy enterprise systems store data in structures that were designed for technical efficiency, not human readability. A customer record in the ERP is not stored as "customer name, loyalty tier, and last purchase date." It is stored across multiple related tables, each identified by a technical code, with values encoded in formats that require contextual knowledge to interpret correctly.
When that data flows through the event bus and arrives in the Customer 360 read model, it cannot arrive in the same technical format. The front-line employee looking at the dashboard should see a customer name, a loyalty status, and a purchase history — not a set of table identifiers and encoded values that require a data dictionary to interpret.
The transformation from technical language to business language must happen at the integration layer — between the legacy system and the event bus — not in the application that displays the data. There are two reasons for this.
First, if the transformation happens in the application, every application that consumes the same data must implement the same transformation independently. Any inconsistency in how two applications interpret the same source data produces inconsistent views of the same customer — which is a new form of the data silo problem, now inside the modern architecture rather than outside it.
Second, the integration layer is the governed boundary. It is where data contracts are defined and enforced. If the transformation logic lives there, it can be tested, versioned, and validated against the business requirements. If it lives in individual applications, it cannot.
This is where the work with data owners became critical. The team responsible for the integration layer could not define the business semantics of the data without the people who understood what the data actually meant in the context of the business processes it supported. A field that stores a numeric code in the ERP might represent a customer segment, a pricing tier, or a regional classification — and the correct interpretation varies by context. No architect can determine that from the schema alone.
THE TECHNICAL CONTRACT: DATA AS A SHARED COMMITMENT
The integration strategy produced something beyond a technical architecture. It produced what the team called a technical contract — a shared, documented commitment between the technical teams managing the integration and the business stakeholders who would depend on it.
The contract specified what data would flow, in what format, at what frequency, with what latency guarantee, and with what error handling behavior when the data quality did not meet the defined standard. It was reviewed and agreed upon by both technical and business stakeholders before the integration went live.
This is the governance discipline that makes distributed data architectures sustainable over time. Without it, the integration is a technical artifact whose behavior is understood only by the people who built it. With it, the integration is an organizational commitment whose behavior can be monitored, challenged, and improved by anyone who depends on it.
The visibility tool that documented the integration — mapping every interface, every transformation, every event flow between systems — served a purpose beyond governance. It served as the lineage record that would allow any future team to understand, without archaeology, how the Customer 360 view was constructed and where to look when something in it was wrong.
THE SOUL OF STRATEGIC EA: THREE PRINCIPLES
Looking back across the full arc of this series — the diagnosis of the silo problem, the selection and design of the EDA and CQRS patterns, the integration strategy that connected them to the legacy system — a set of principles emerges that are more durable than any of the specific technical decisions made.
[1] MINDSET BEFORE METADATA
The tools available for data architecture in 2026 are genuinely powerful. Event buses that can process millions of events per second. Cloud data stores that scale elastically to any read volume. Integration platforms that can map between data models with minimal code. They are impressive. They are not the reason this architecture delivered value.
The reason was the clarity of the architectural thinking that preceded any tool selection. The decision to shift from a polling model to an event-driven model was not made because EDA was the current best practice. It was made because a specific concern — real-time data availability without ERP performance degradation — had been clearly named, and EDA was the minimum solution that addressed it.
An organization with clear architectural thinking and adequate tools will consistently outperform an organization with world-class tools and unclear thinking. The tools amplify the thinking. They do not replace it.
[2] CONTEXT IS THE DECIDING FACTOR
The patterns described in this series — EDA, CQRS, zero-impact integration — are not universal prescriptions. They were right for this problem, in this organization, with these constraints, at this moment.
A different organization with different latency requirements, a different legacy system, a different tolerance for eventual consistency, or a different competitive context might reach different architectural conclusions — and should. The value of a pattern is not in its general applicability. It is in its specific fit to the problem at hand.
This is the discipline that separates a strategic architect from a technically skilled one. The strategic architect does not ask "what is the best pattern for this class of problem?" They ask "what is the specific concern that needs to be resolved, and what is the minimum, most appropriate response to it?" The answer may look like a recognized pattern. It may not. What matters is the reasoning, not the recognition.
[3] PEOPLE ARE THE LIVING ARCHITECTURE
Of all the decisions made in this engagement, the most consequential were not technical. They were human.
The decision to begin by asking front-line employees what information would change how they work, rather than beginning with a data model. The decision to involve data owners in the semantic translation work rather than assuming the integration team could interpret the source data correctly. The decision to treat the technical contract as a shared organizational commitment rather than a technical specification.
These decisions produced an architecture that was validated by the people who would use it before it was built, not after. They produced a data flow that business stakeholders understood and trusted, not one they were asked to accept on faith. And they produced an organization that was engaged in the modernization rather than subjected to it.
Target Architecture is not complete when the last diagram is approved. It is complete when the people who depend on it confirm that it resolves the concerns that motivated it — and that it has genuinely changed how they work for the better.
That is the measure of a Fit-for-Purpose architecture. Not the sophistication of the patterns. Not the modernity of the platform. The confirmation from the person on the front line that the system the architects designed actually helps them serve the customer better.
Systems are built with technology. Architectures are crafted with thinking. And the value of both is ultimately validated by the people who use them.
Raschada Nootjarat is an Enterprise Architect with a focus on AI strategy, architecture governance, and the intersection of human and machine systems in organizational transformation. She starts this website together with her "Fit-for-Purpose Enterprise Architecture" book in April, 2026.