Legacy integration connects an existing application to newer software while preserving the business behavior people rely on. A useful first step is often a small, well-defined interface around the old system: an order lookup, inventory feed, or customer update.
AI coding assistants can help investigate a repository, draft adapters, and propose tests. They still need evidence about the real system: input formats, transaction boundaries, access rules, and behavior that may never have been documented. Treat their explanation as a hypothesis to verify against code and observed results.
Choose an integration boundary
Start with the capability another application needs, rather than a plan to replace the entire system. Identify who owns its data, which callers depend on it, and how much delay or downtime those callers can tolerate.
| Approach | Useful when | What to establish |
|---|---|---|
| API wrapper | A caller needs a specific request and response. | Identity, input validation, errors, timeouts, and transaction behavior. |
| Batch export | A report can use a periodic snapshot. | Cutoff time, completeness, encoding, and restart behavior. |
| Events or change feeds | Consumers need updates as business data changes. | Ordering, duplicate delivery, schema changes, and replay. |
| Incremental replacement | A capability needs a new implementation. | Traffic routing, result comparison, and data ownership during transition. |
SOAP and XML may remain appropriate where an existing contract requires them. Adding a JSON interface does not require rewriting every internal component. Microsoft's Strangler Fig pattern describes gradually routing capabilities to a replacement behind a facade; that facade also becomes a component that needs monitoring and maintenance.
Discover behavior before changing it
- Map one path. Follow an input through parsing, business rules, storage, and the returned result. Ask the assistant to cite the files and functions behind its explanation.
- Collect representative examples. Use synthetic or approved, sanitized records. Include missing values, unusual characters, and boundary values.
- Record current behavior. Characterization tests capture what the old system actually does. Review unexpected behavior with its owner: a passing test can preserve a defect as easily as a requirement.
- Define the external contract. Specify fields, types, errors, authentication, and versioning before generating an adapter.
Keep identifiers as identifiers. An account number such as 00127 must not lose its leading zeros because generated code inferred an integer. Similarly, establish decimal precision, date interpretation, and text encoding explicitly.
Worked example: expose an order lookup
This is a proposed contract, not a runnable service. Test it against fixtures before connecting the real system. Expected cases include a valid order, an absent order, a forbidden order, a timeout, and an unrecognized status. Decide deliberately whether absent and forbidden results should be distinguishable to the caller.
A useful assistant prompt is: Inspect the order lookup path and cite the relevant functions. Propose a read-only adapter that preserves string identifiers and integer cents. First write a contract and tests for success, missing records, denied access, timeout, and unknown status. List unresolved assumptions before implementing.
Move from a prototype to production
Start with a limited set of callers. Compare old and new responses using the same approved test inputs, then measure error rates and latency. Shadow comparisons should avoid duplicating writes or exposing data to an unauthorized consumer.
Write integrations need additional design. If an order creation request times out after the old system commits, retrying may create a second order. Use a durable business operation identifier and a way to discover whether the first request completed. A wrapper cannot promise duplicate prevention that the underlying transaction does not support.
Document a rollback condition, such as a sustained increase in mapping errors, and a tested routing change to restore the previous path. Rolling back code does not reverse data already written; schema and data changes need their own recovery plan.
Maintain a small record for each adapter: owner, contract version, dependencies, credentials source, timeout policy, and last verified examples. This gives future developers and their coding assistants reliable context.
Common questions
Should AI rewrite the whole application?
A bounded change is easier to compare with existing behavior. A broader rewrite needs a separate case based on maintainability, platform constraints, and migration cost.
Does generated code make an integration correct?
Correctness depends on the contract and observed behavior across both systems. Compilation is only an early check. AI review should complement human review, as GitHub's code review guidance also emphasizes.