Buyers can compare legacy integration approaches by analysing what data format the web application receives and where the translation layer is positioned. It is essential to assess whether the proposed architecture explicitly provides for control points such as authorisation and rate limiting, and whether a middleware layer with protocol transformation is required in the absence of stable REST or SOAP endpoints.
Comparison of legacy integration options
When choosing between an API layer, custom middleware, or a direct connection for legacy integration, it is important to understand the technical and operational implications of each option.
- An API layer provides a standardised gateway that translates internal data structures into a uniform interface.
- Custom middleware acts as a standalone component that transforms data and protocols and provides additional logic.
- Direct connections link the web application directly to the legacy system, which can introduce vulnerabilities.
- Assess whether the integration architecture includes security measures such as authorisation and rate limiting.
- Analyse how responsibility is allocated for data validation, network security, and data transformations.
The importance of middleware when modern interfaces are unavailable
When a legacy system does not provide stable REST or SOAP endpoints, a new web application cannot simply connect directly to that access point. If the available interaction is limited to raw database access or files, the proposal must describe how that form of access will be made usable for the new application.
A middleware layer then has a clearly defined function: protocol transformation. The web application and the legacy system do not automatically use the same method of data exchange. Middleware is the place where the available form of access is converted into a form that the new application can use. In this role, it can also function as an Anti-Corruption Layer (ACL): a boundary that prevents outdated formats and technical assumptions from entering the web application directly.
This distinction is particularly relevant in proposals where terms such as API, integration, and connector are used interchangeably. Those terms alone do not mean that the existing system supports REST or SOAP. With database-only or file-based interaction, protocol transformation must therefore be an explicit part of the solution. Otherwise, it remains unclear how the new application actually communicates with the available legacy access.
The practical test is simple: describe, for each data flow, which stable interface the legacy system provides. With REST or SOAP, a proposal can connect to it. With a database or file, the solution should include a middleware layer with protocol transformation. This makes the technical dependency visible before the web application is assessed on screens, features, or planning.
Middleware does not solve the entire integration challenge and, by itself, says nothing about the further design of the web application. Its role is more specific: it fills in the missing modern interface where the legacy system does not provide one. The presence of raw database access or files is therefore a concrete reason to include protocol transformation as part of the solution.
Comparison of integration options for legacy systems
In addition to the technical choice, the integration option primarily determines where maintenance work ends up. Therefore, compare proposals not only by the component named, but also by the consequences for changes in field definitions, error handling, and connection management.
With an API layer, the maintenance boundary generally sits around the uniform interface. Changes in internal structures can be absorbed there, provided the proposal makes clear who manages the interface and the associated contracts. With custom middleware, that boundary is often broader, as validation, message handling, or asynchronous processing can be accommodated alongside transformations. This requires a clear owner for both the logic and the monitoring.
A direct connection brings these responsibilities closer to the web application. As a result, changes to database, driver, or file interfaces can affect the application more quickly. It also raises the question of which party maintains the technical details of the old system when the connection needs to be adjusted.
For legacy integrations, this distinction matters because it determines where the translation of protocols and field definitions takes place and who is responsible for shielding technical details. By analysing for each proposal what data format the web application receives, what changes are expected, and who manages the translation layer, you gain insight into the actual scope and maintenance impact of the chosen integration architecture.
When does the choice of an integration option become relevant?
The choice between an API layer and middleware becomes relevant as soon as a new web application needs access to data or functionality from an existing system. At that point, not only technical reachability matters, but also how that access is regulated and protected. An available interface creates an access surface where object-level authorisation and request limits may be necessary to reduce vulnerabilities and overloading of the legacy system. According to the OWASP API Security Top 10, integrations should therefore provide authorisation control per object (API1:2023) and strict rate limiting (API4:2023). So assess whether the proposal assigns these control points concretely, rather than merely naming an architectural label. The relevant question is whether the chosen design organises and protects access to the legacy system.
Comparison criteria for integration options
Maintainability, security, and responsibilities become comparable when each proposal explicitly assigns the same tasks. A RACI matrix makes this allocation verifiable: it shows not only the chosen layer, but also the owner of validation, network access, transformations, and keys.
| Comparison criterion | What the proposal makes explicit | Meaning for API layer, middleware, or connection |
|---|---|---|
| Data validation | Who is responsible for checking data before it is processed or passed on. | Maintainability requires a named owner. Without allocation, it remains unclear whether validation belongs to the web application, the integration layer, or the operator of the existing system. |
| Network security | Who manages network security, including VPN and IP whitelisting. | The security implication does not lie in the label API layer or middleware, but in explicit responsibility for the connection used by the component. |
| Data transformations | Who manages and maintains the conversion between data formats. | For an API layer or middleware, this is the distinguishing maintenance consideration. It lets the buyer see whether transformations are included as a separate management task or remain an unnamed assumption within the connection. |
| Authentication keys | Who performs authentication key management. | A connection is only operationally defined when key management has an assigned responsibility. This makes it clear which party manages access. |
| Proposal maturity | A detailed RACI matrix that records all the tasks mentioned. | The matrix normalises proposals with different architectural names: the same responsibilities are assessed side by side, even when suppliers propose different components. |
Trade-offs and limitations of integration options
An architectural choice only becomes testable when it is linked to a clearly bounded use case. This prevents a proposal for an API layer, middleware, or direct connection from being assessed merely as a broad promise. Start with one process whose data flow, exceptions, and acceptance can be described in advance; expand the scope only afterwards.
- Scope versus evidence. A broad integration scope may appear attractive, but it makes it more difficult to determine whether the proposed approach actually works for the data flow that matters. A proposal can therefore be limited to one fixed document or transaction type. This limitation does not imply that other integrations are unnecessary; it creates a testable initial unit. Define in advance when that first unit is accepted, without assuming a general performance threshold. The relevant comparison point is that suppliers include a concrete use case and an explicit acceptance boundary before additional integrations are implemented. This shifts the assessment from an abstract choice between an API layer and middleware to the question of which approach demonstrably meets a predefined scope.
- Expansion versus manageability. A phased expansion can align with the Strangler Fig Application Pattern: new functionality is gradually placed around the existing core without immediately replacing all processes. With asynchronous processing, the proposal should also make clear how Backpressure Management is applied when the legacy system can process fewer requests than the new application submits, and how Eventual Consistency is handled when data is not immediately the same everywhere. This ensures the technical consequences of expansion remain part of the assessment.
Practical application of integration options
The practical application of integration options starts with limiting risks and making responsibilities explicit. The steps below help you compare API layer or middleware proposals concretely and assess them for feasibility and security:
- Start with read-only access. Explicitly request an initial phase in every proposal in which the new web application only reads data from the existing system. This approach—a phased migration path with read-only functionality—makes it possible to expose data without immediately changing the primary system. It limits the risk of production downtime or data corruption and makes the difference visible between suppliers that want to implement mutations immediately and parties that propose a step-by-step approach.
- Define the functional boundary. Record for each proposal which functionality is read-only in this phase, which system is considered the source, and how the supplier ensures that this boundary is not exceeded. This makes it possible to compare the degree of control and responsibility for each architectural option.
- Assess the positioning of the integration layer. Look not only at the component's name (API layer, middleware, connector), but at how this layer is positioned: is the connection placed alongside the existing system, or does it intervene directly? An integration layer as a buffer can limit the web application's dependency on legacy details. For processes that write to two systems, the Dual-Write Penalty also deserves attention: the proposal must make clear how duplicate mutations and diverging data states are managed.
Frequently asked questions about integration options
Questions about API layers and middleware often concern normal processing. However, the operational quality of an integration is also demonstrated by how it handles a stalled transaction and makes it explainable afterwards. The proposal should therefore make these provisions visible.
- “Is a working connection sufficient when the normal data flow has been described?”
Not if the proposal contains no provision for transactions that cannot proceed. A transparent integration architecture demonstrably reserves budget and components for centralised audit logging, Dead Letter Queue monitoring, and concrete recovery procedures for stalled transactions. This makes the exceptional situation part of the proposed solution rather than an implicit task after go-live. The question therefore shifts from “can the connection process data?” to “where does a stalled transaction become visible, and what recovery procedure is provided?” - “Is logging the same as recovery?”
No. Centralised audit logging enables recording, whereas concrete recovery procedures describe what happens to a stalled transaction. Dead Letter Queue monitoring adds a separate view of messages that have not been processed normally. These three elements each have their own place: recording, signalling, and recovery. A proposal that mentions only one of them does not automatically describe the other two. - “Does an API layer mean errors are handled automatically?”
No. The name of the layer does not mean that audit logging, Dead Letter Queue monitoring, or recovery procedures are included. These provisions should be recognisable as architectural components and as reserved budget. The same applies when the proposal refers to middleware or a connector. Therefore, compare whether these elements are explicitly included, not whether a supplier uses a particular integration label. - “Why should this already be included in a proposal?”
Because otherwise a stalled transaction has no predefined route for detection and recovery. By demonstrably reserving logging, monitoring, and recovery, it becomes clear which operational activities the solution does and does not include. This makes responsibility for exceptional processing discussable before the integration is in use.
Key considerations when choosing an integration option
The final choice follows from the combination of technical access, management, and demonstrability. Therefore, compare proposals using the same decision points, not the appeal of the term used.
- First test the actual access. For each data flow, record which interface the legacy system actually provides and where any protocol transformation takes place. This clarifies whether an API layer, middleware, or direct connection technically fits the available access.
- Make ownership verifiable. Use a RACI matrix for validation, network security, transformations, and authentication keys. This makes clear who carries out changes, security measures, and day-to-day management.
- Assess the first use case and the exceptions. Request a defined document or transaction type with an explicit acceptance boundary. Also check whether audit logging, DLQ monitoring, and recovery procedures are included. A proposal is only truly comparable when both the normal data flow and exceptional processing have a named place.