Legacy system integration without rewrite: where AI fits

01Can you connect AI without replacing the existing system?

Often, yes, if a supported interface exposes the information or action you need. First check whether the problem is access to a working process or a process that already produces unreliable outcomes.

Integration preserves the existing application while adding a connection. Modernization changes parts of that application. Neither automatically makes its records accurate or its business rules suitable.

AWS describes the Strangler Fig pattern as incremental replacement of functionality rather than a single migration. That is a possible future path, not a requirement for every AI pilot. Its implementation also needs appropriate access and introduces routing and consistency concerns.

For a first project, choose a narrow outcome such as preparing an order-status response. Keep the original system authoritative for order status. If you are still choosing the process, start with our first-90-days operations guide.

02Which connection should your team assess first?

Assess the supported route that exposes the required operation with the fewest unnecessary permissions. The table below is our decision aid, not a ranking that applies to every system.

Microsoft's desktop-flow documentation describes automation across legacy and modern applications through interface elements, images, or coordinates. This establishes an available technique, not compatibility with your particular application.

Ask the system owner to demonstrate the proposed route in a test environment. A connector's existence does not establish permission to use it, suitability for production, or permission to send its data to an AI service.

03What should sit between AI and the old application?

Use a controlled boundary that translates the few operations the pilot needs. Keep data interpretation, permission checks, and execution distinguishable.

Microsoft's Anti-corruption Layer pattern explains how a translation layer lets systems communicate without forcing one to adopt the other's internal model. It also adds maintenance and latency, and requires attention to data consistency.

Our practical recommendation is to expose a named task such as “retrieve order status,” with defined fields and errors. Avoid handing the model a general-purpose account and expecting a prompt to enforce all limits. Technical controls should constrain accessible records and available actions.

The AI might turn a customer message into a proposed lookup and draft a response. A deterministic check confirms the record match; a person resolves ambiguity. The AI, RPA, and agent comparison helps distinguish those roles.

04How do you define a pilot your team can actually approve?

Write a one-page operating agreement before connecting production access. Our suggested sequence makes each permission depend on evidence from the preceding step.

1. Name the outcome. Specify the record, user, and completed task. Done when the process owner can demonstrate a normal case and an exception.
2. Define the read boundary. List permitted fields, record scope, freshness, and destination. Done when the data owner approves that exact scope.
3. Separate proposed changes. List what the AI may suggest and what it may execute. Done when each write has an approval rule and a way to verify its result.
4. Define recovery. Specify who handles stale data, duplicate requests, and an unknown execution outcome. Done when the team can show the manual path without guessing whether a change happened.
5. Test before expanding. Run representative cases and failures in a controlled setting. Done when the owner reviews the evidence against agreed pass conditions, including review effort.

For example, a successful network response alone need not prove that the business process finished. Decide which record or receipt demonstrates completion and where that evidence is retained.

05What would an order-status pilot look like?

A read-first pilot can prepare a useful response without giving AI authority to change the order. The following is a hypothetical scenario, not a client case or a reported result.

A support team receives a message asking whether a shipment has left. AI proposes an order reference from the message. A restricted lookup retrieves the matching order and the time its status was last updated. The response draft includes that status for a support specialist to check.

If two orders match, the workflow requests clarification. If the record is too old for the team's agreed freshness rule, it goes to a specialist rather than presenting an old status as current. If the customer asks to change the delivery address, that request enters a separate approval process.

The useful pilot result is evidence about this bounded workflow: whether records match, whether reviewers can detect problems, and whether exceptions reach the right person. No savings or accuracy claim follows merely from connecting the systems.

06When should you stop and reconsider the approach?

Stop when the connection cannot preserve a trustworthy operating boundary. An unsupported access route, unclear record ownership, or an untested recovery path is a reason to narrow the project or reconsider replacement.

Ask your team to demonstrate what happens when the same request arrives twice, access expires, the source changes during processing, or an action times out after it may have completed. An uncertain write should be investigated before it is repeated.

Also agree who maintains the connection when the legacy application changes. “No rewrite” still requires ownership, testing, and support.

Bring one candidate workflow, its source system, and its exception path to an AI Opportunity Audit: Book a 30-minute call.

07Frequently asked questions

Sources and further reading

1. Strangler fig pattern. AWS, Accessed 2026.
2. Introduction to desktop flows. Microsoft, 2026.
3. Anti-corruption Layer pattern. Microsoft, 2026.