A warehouse supervisor enters 71 into a green-screen order field every time a shipment leaves with a substitution. The code is absent from the vendor manual. It appears in three reports under two labels, and the employee who taught the team the rule retires in November.
An integration vendor can expose that field through an API in a week. The API would make the uncertainty travel faster.
Legacy system integration services should begin with an audit of the seam between old and new, not a promise to connect them. The seam includes the supported access path, the business language trapped behind short codes, the writer for each fact, and the changes the bridge will have to survive. Architecture comes after those unknowns have names.
Audit supportability first
The age of a system tells you very little about whether it can be integrated safely. A twenty-year-old application with a supported export and stable owner may be easier to connect than a five-year-old custom app with direct database writes and no tests.
Collect six pieces of evidence:
| Evidence | What it settles |
|---|---|
| Vendor support statement | Which APIs, database views, messages, or exports are supported and for how long |
| Redacted interface sample | The actual shape, codes, nulls, limits, and error responses |
| Change record | Which fields, screens, versions, and authentication methods changed in the last two years |
| Load sample | Ordinary volume, peak volume, largest payload, and longest backlog |
| Incident sample | A recent timeout, rejected record, duplicate, or operator workaround |
| Named owners | Who can approve access, define the business meaning, and accept ongoing operation |
Put unresolved items in an unknowns register. Give each one an owner, evidence request, decision date, and consequence if it stays unknown. “Vendor will confirm during implementation” is not resolution. It is a cost and risk transfer back to the buyer.
A database view can be a sensible read seam. A direct database write may skip the application’s business rules. A scheduled file may be perfect for yesterday’s reporting and useless for a reservation that must appear in seconds. Supportability is a property of the job and the access path together.
Our legacy application modernization services guide owns the wider retain, retire, rehost, refactor, rebuild, or replace decision. This page starts after a bounded legacy capability has earned the right to remain.
Choose among three bridge shapes
Most proposals become clearer when the bridge is named by what it is allowed to do.
Read mirror
A read mirror copies approved legacy records into a store shaped for reporting, search, portals, or new applications. The legacy system remains the writer. The mirror can lag by an agreed interval, and consumers must know they are reading a copy.
This is the lowest-conflict shape. It still needs deletion rules, reconciliation, access controls, and a response when the source changes its schema.
Command gateway
A command gateway accepts a narrow request such as create work order or place approved credit hold. It validates the caller and payload, translates the request, invokes the legacy system through a supported path, and returns a business result.
The gateway is not a general write API. Its permitted verbs, limits, identities, timeouts, and uncertain outcomes are part of the contract. If the old system accepts a request but fails to return a clear response, the gateway needs a safe way to discover the result before another command is issued.
Event relay
An event relay publishes selected legacy changes for multiple downstream consumers. It fits when consumers should react without querying the source on every request. The relay needs stable event identity, ordering rules where order matters, and a repair path for subscribers that fall behind.
Do not buy bidirectional synchronization as a fourth vague shape. Combine explicit shapes instead. A read mirror may carry customer reference data outward while a command gateway sends one approved action inward. The direction and authority stay visible.
Recover the business language
Code 71 is not a mapping problem until someone knows what it means. The new system should not inherit that ambiguity under a friendlier field name.
For each exchanged value, record the source meaning, business owner, allowed states, destination meaning, transformation, missing-value treatment, and rejection rule. Use examples that include the awkward cases. A map containing only the ten most common values is a demo fixture, not an interface definition.
Microsoft’s Anti-Corruption Layer pattern places a facade or adapter between systems with different semantics. It lets the new side use its own model while translation stays at the boundary. Microsoft’s guidance also names the bill: latency, another service to manage, transaction and data consistency, monitoring, release work, configuration, and a choice about whether the layer is permanent.
That makes translation logic owned software. Version it. Test it. Put changes through a business approver who understands both meanings. If nobody can approve what 71 becomes, the integration is not ready.
Protect the writer
Every business fact needs one current writer. A second system can propose a change or hold a derived copy, but two uncoordinated masters will eventually disagree.
Mark each exchanged field as legacy-owned, new-owned, derived, or human-resolved. Then forbid writes that cross the rule. Split ownership can work when the split follows real business authority, such as finance owning credit status while service operations owns the visit window. It fails when the split is merely convenient for the implementation team.
Blind dual writes are especially brittle. A process that commits a record and then publishes a message can stop between the two operations. Microsoft’s transactional outbox guidance describes one response: save the business change and its event in the same transaction, then let a worker publish the stored event. The guidance also notes that event order still needs deliberate handling.
The pattern is useful where it fits. The buyer still needs to decide who owns the fact, what a repeated event does, and how an operator recognizes an uncertain result.
Balance the books independently
A bridge dashboard can show every message as delivered while the warehouse holds 8,402 orders and the ERP holds 8,399. Delivery is a transport result. Agreement is a business result.
Pick a balance for each bridge shape. A read mirror may compare row counts, totals, missing identifiers, and age of the last accepted change. A command gateway may compare requested commands with confirmed business records and unresolved outcomes. An event relay may compare source change positions, published events, consumer offsets, and quarantined records.
AWS Database Migration Service is only one product example, but its documentation makes the separation visible. AWS treats change-data capture and data validation as distinct work. Validation compares corresponding rows and reports mismatches. Moving a change and checking the result are different controls.
Write down who reviews the balance, how much difference is tolerated, and which repair actions they may take. A mismatch queue without an authorized operator is merely a record of accumulating debt.
Secure the old system from its new audience
An integration may introduce callers, networks, request rates, and data uses the legacy application never faced. Treat the seam as a trust boundary even when both endpoints belong to the same company.
NIST SP 800-228 organizes API risk and protection across development, pre-runtime, and runtime stages. For a legacy bridge, that means named workload identities, operation-level authorization, input and output validation, controlled secrets, endpoint inventory, network restrictions, resource limits, security logs, and removal of access when the bridge closes.
Ask what the old system can actually enforce. If it offers one broad service account, the adapter may need to narrow callers and commands while the risk owner records what remains broad underneath. Calling the account “integration-user” does not reduce its privilege.
Test the next change
Happy-path demonstrations answer whether the bridge works today. Acceptance should answer whether the team can change it next quarter.
Choose the likeliest disruption from the evidence: a new status code, an added required field, a certificate rotation, a larger file, a slower response, or a supported version upgrade. Introduce it in the test environment without telling the operator exactly where it will surface.
Observe the chain. Did a compatibility test stop the release? Did monitoring identify the affected bridge rather than report a generic error? Could the operator find the mapping owner? Was rollback possible? Did reconciliation prove that no records disappeared during the change?
This drill tests the operating system around the adapter: source knowledge, fixtures, release control, observability, authority, and repair. A provider can memorize a failure demo. An unannounced but realistic change is harder to bluff.
Price the operating tail
The first build is only the opening cost. The bridge inherits change from both endpoints plus its own runtime, credentials, mappings, queues, logs, and dependencies.
Ask each provider to list recurring duties without inventing a five-year estimate:
- vendor and interface version review;
- mapping and compatibility-test maintenance;
- credential rotation and access review;
- capacity and backlog review;
- reconciliation and mismatch repair;
- incident coverage and dependency escalation;
- runbook and owner updates; and
- security findings and library upgrades.
Assign each duty to the buyer, provider, software vendor, or a shared process. If a proposal ends at deployment, the receiving team needs time and authority to rehearse those duties before acceptance.
Give temporary architecture an expiry test
A bridge may be permanent infrastructure or scaffolding for phased replacement. Both are legitimate. Undeclared status is not.
For a temporary bridge, name the capability that will replace it, the evidence required to shift traffic, the rollback window, the data-exit work, and the condition for shutting the old route. The AWS Strangler Fig guidance uses a proxy to route work between legacy and new components during incremental replacement. AWS also notes non-fit cases, rollback needs, and the risk that the proxy becomes a bottleneck or single point of failure.
For a permanent bridge, give it a service owner, operating budget, review date, support path, and tested restoration procedure. Remove “temporary” from the paperwork. It prevents the team from deferring maintenance while waiting for a retirement project that nobody funded.
Compare providers by what remains unknown
The strongest proposal will not claim that every old system can be connected cleanly. It will reduce the expensive unknowns before quoting the full build.
Ask each provider to return the supportability evidence, chosen bridge shape, semantic mapping sample, writer map, independent balance, trust boundary, change-drill plan, recurring-duty split, and lifecycle decision. Beside each item, keep the unknowns that remain and the decision they block.
That register is more useful than a connector count. It shows whether the provider inspected the system or simply recognized the product category.
GM Ware’s Integration & Data Sync work covers scoped data movement with validation, audit history, alerts, access controls, and documented handoff. It does not promise universal compatibility or safe access to every legacy product. Bring a redacted interface sample, one undocumented code, the vendor support statement, and a recent change ticket. Those four items are enough to begin the seam audit.