Where should integration begin?
Choose a workflow where staff spend time moving information or preparing routine decisions across systems. Identify the system of record and the person accountable for each action. Start with assistance, such as retrieving approved information or drafting a request, before allowing the agent to change business records.
Use supported interfaces where available and define exactly what each action can do. Validate inputs and outputs outside the model. Preserve existing business rules and transaction checks. If a legacy application lacks a suitable interface, assess the maintenance burden and failure modes of any adapter before committing to it.
Determine whether an action uses the employee's permissions or a dedicated service identity. Grant only the access required for the workflow and protect credentials outside prompts. Treat retrieved text as information, not as permission to execute instructions. Log meaningful actions without unnecessarily copying sensitive data into diagnostic records.
Plan for partial failure
An agent may time out after a transaction succeeds. Use transaction identifiers and checks that prevent duplicate updates when work is retried. Define what happens when one system is unavailable or data disagrees across systems. Provide clear messages and a practical handoff so staff can finish the task without guessing what already happened.
Test with representative records, then move to a limited pilot. Compare quality, completion time, support effort, and operating cost with the existing process. Review errors before expanding permissions or user access. Keep a rollback route and name the team responsible for ongoing integration maintenance. Include the application owner in each pilot review and agree on who can pause the integration when problems appear.
Trace one business transaction across the existing stack
Ask employees to demonstrate a task using the current applications. Record each lookup, copied value, approval, and update. Include the spreadsheets or messages that connect official systems. The purpose is to identify the authoritative record and the real handoffs, not just produce an inventory of software names. Those details determine where an agent can assist without confusing ownership.
For an illustrative customer service request, the agent might retrieve an order status and prepare an internal case. Updating the order or promising a delivery date remains a separate decision. Choose an initial boundary that is useful and reversible. A narrowly scoped workflow can demonstrate value while exposing integration limitations before the organization authorizes more consequential operations.
Document the business contract for every connection
Specify the information an operation accepts, the record it reads or changes, and the evidence that confirms success. Include the permission under which it runs. The application should preserve existing business validation rather than treating a generated instruction as authority to bypass it. If a supported interface is unavailable, assess the fragility and maintenance effort of any workaround explicitly.
WTA's platform modernization services assess these dependencies and staged improvement options. AI-native product engineering connects the selected interfaces to the employee experience. A useful design makes system limitations visible, including delayed updates and operations that cannot be safely reversed, so the business owner can make an informed decision about the pilot scope.
Rehearse partial completion before live use
Imagine that a case is created successfully but the confirmation never reaches the agent. The recovery process must check whether the record exists before repeating the operation. Now consider one system succeeding while another is unavailable. Define the status the employee sees and which team owns reconciliation. These are ordinary integration questions that become more important when a conversational interface hides technical detail.
Test cancellation and repeated requests with the same care. An employee should not accidentally submit two transactions because the first attempt appeared slow. Preserve references that help support identify completed work. Keep a practical manual route so staff can finish the business task while the integration is being investigated, without relying on guesses about what the application has already done.
Expand by capability rather than by enthusiasm
Review accepted task completion, correction effort, support demand, and total cost after the first release. Ask whether the workflow reduced the employee's overall work or merely changed where it occurs. Include the effort needed to maintain connections when the legacy system changes. A successful demonstration may depend on assumptions that are not stable enough for daily use.
Introduce each new action through a separate assessment of permissions, business rules, and recovery. Reuse proven connections where appropriate, but do not assume that read access justifies write access. Keep the application owner involved as the service expands. Modernization should improve the organization's ability to operate and change its systems, not create another dependency whose behavior nobody can adequately explain.
Frequently asked questions
Must we replace the legacy application first?
Not always. A bounded workflow may use supported interfaces while the existing application remains authoritative. Assess the integration, access, and maintenance requirements before deciding. Some limitations justify modernization first, while others can be managed within a narrow pilot. The appropriate choice depends on the business task and operating evidence.
Can an agent bypass an application limitation?
Any workaround still needs assessment for permissions, business rules, reliability, and support. A conversational request does not remove the limitation or grant authority to ignore it. Make the workaround's assumptions visible and compare its maintenance burden with improving the underlying interface or changing the proposed scope.
What is a suitable first integration?
Choose a useful task with clear information ownership and limited consequences, such as retrieving approved records or preparing a draft request. Define success and escalation before implementation. This allows the team to evaluate the employee experience and integration reliability before authorizing actions that materially change business records.
How do we avoid duplicate actions?
Use the connected system's supported transaction controls and check the actual result before retrying an uncertain operation. Preserve references that support investigation. Test interruptions and repeated requests explicitly. The employee should receive an accurate status and a recovery route instead of being encouraged to repeat the task without knowing what completed.
Updated September 18, 2026. Related: Connecting Enterprise Search to Legacy Systems.
.svg)
.svg)
.svg)
.svg)
.svg)
.png)
.svg){kind=small}
.png)