Integrating AI with legacy systems: challenges and options

AI can now read your purchase orders. Entering what it read into the sales management system, though, is still done by hand. Plenty of companies pushing ahead with AI stall right here, because older core systems sometimes have no API for getting data in or out.

This article covers the challenges of connecting AI to core systems that have no API (legacy systems), and how to connect them without waiting for a rebuild, in the order to choose.

The short answer: don’t wait for a rebuild, connect wherever there is a way in

• To read data, start from an API or the core system’s export function. If neither exists, read the database (without writing to it)
• To write data, start from an API or the core system’s import function. If neither exists, operate the screens
• Before writing to the core system, a person checks
• Record each connection in a ledger, and swap it for an API when the system is rebuilt

Why legacy systems hold AI back

In 2018, the DX Report from Japan’s Ministry of Economy, Trade and Industry warned of legacy systems as the “2025 digital cliff”. The problem is still there after 2025.

According to DX Trends 2025 from IPA, Japan’s Information-technology Promotion Agency, of 1,516 Japanese companies that responded in fiscal 2024, 34.2% said legacy systems (aging existing IT systems) remain in some areas, 13.0% that about half of their systems are legacy, and 15.5% that most are: 62.7% in total. IPA notes that the trend barely changed from the year before, and that renewal appears to have plateaued.

Companies that have started using AI hit the same wall. In a September 2025 survey by Cloud Ace of 111 people in IT, DX, and AI departments who use AI agents at work, the top challenge was that integration and connection with existing systems is complex (51.4%). In IPA’s DX Trends 2026, too, 23.3% of companies named “existing systems can’t support it” as a challenge in preparing, managing, and sharing data.

AI only helps where it can receive data and return results. Without a connection to the core system, manual re-entry remains before and after the AI, and the work barely shrinks.

Six challenges in connecting to core systems with no API

1. No way to get data out

Data in a core system may be visible only on screens or in printed reports. Even with an export function, it may run only as a nightly batch, or leave out the fields you want to give AI.

What to check:

• Which data and fields can be exported, and when (on demand, or only overnight)
• Whether the export can run without a person (by command or on a schedule)

2. No way to put data in

Entering the orders or invoices that AI has read needs a way in. Even with an import function, the format may be strict, and it may be unclear how rows that fail are handled.

Avoid writing directly to the database. It skips the input checks and linked processing the application performs when data is entered on screen. With packaged products, it can also take the system out of vendor support.

What to check:

• Whether there is an import function, and its format (field order, character encoding, date format)
• Where and how rows that fail to import are reported
• Whether the maintenance contract sets conditions on imports or operations from outside

3. Screens that resist automation

Dedicated client apps, terminal emulators for host systems (mainframes and midrange office computers), and old web screens were all built for people. RPA that records screen elements or positions tends to stop when screens are updated or the resolution differs (Why RPA bots break when screens change).

AI that reads and operates the screen copes better with change, but it has limits. Anthropic, describing its computer use tool, says reliability might be lower when interacting with niche applications. Core system screens built for in-house use can be exactly that.

What to check:

• How long one entry takes, and how many there are a day. Can screen operation keep up?
• Can the values entered be read back from the screen and checked before saving?
• For host terminals, can you use an RPA product’s terminal emulation features, or file transfer on the host side?

4. Reachable only from inside

It is not unusual for a dedicated client to be installed on certain PCs only, or to work only inside the company network or over a VPN. Some core systems sit in closed networks cut off from the internet. AI services running in the cloud cannot reach these systems directly.

Anthropic advises running computer use in a dedicated virtual machine or container with minimal privileges.

What to check:

• Which PCs can use the core system, and how they sign in
• Whether a PC or virtual machine (VM) dedicated to automation can sit on the same network as the core system
• Whether communication with the outside, including AI model providers, is allowed
• Whether the account used for automation also needs a core system license

5. AI mistakes go straight into the core system

AI doesn’t read correctly every time. A wrong item code or quantity entered as an order spreads to shipping, billing, and accounting, and is hard to fix later.

What to check:

• Who checks what before anything is written (every item, or only those that failed matching)
• Whether the core system has a procedure for canceling or correcting entries
• Whether it is recorded when, what, and with whose approval each entry was written

6. Nobody knows what is connected where

RPA bots built by each department, personal macros, nightly scripts. The more ways you connect, the harder it is to know what is connected to which part of the core system. When the time comes to rebuild it, this becomes a new black box.

What to check:

• Is there a list of the connections (screens, files, databases) and who owns each?
• If the person who built one moves on, can someone else fix it?

The list can follow the same approach as How to build a robot ledger for RPA, with a template.

Four ways to connect, compared

Way to connect	Changes to the core system	High volume	Effect of screen changes	Watch out for
API	Development needed if none exists	Suits it	None	Vendor support and cost
Files (import and export)	None, using existing functions	Suits it	None	Format, character encoding, handling of failed rows
Reading the database	None	Suits it	None	Read only. Table structures can change with upgrades
Screen operation (RPA or AI)	None	One item at a time, slow	RPA tends to stop, AI looks again	The PC it runs on, sign-in, checks before writing

The order to choose in

1. If there is an API, use it: fast, and stable at high volume
2. If there are import or export functions, use files: hand data over in bulk without touching the core system
3. If you only need to read, read the database: never use it for writing
4. Operate the screens for the entry and checks that remain: this replaces, as is, the work people do on screen now

Mixing them within one process is fine. You might read the product master from a file exported overnight, and enter only the orders through the screen.

Example: reading purchase orders and entering them in the core system

Here is the work of entering purchase orders that arrive by email into a sales management system with no API, split step by step.

Step	Who does it	How it connects to the core system
Save the attachment from emails with purchase orders	Fixed steps	None
Read the customer, item code, quantity, and delivery date	AI	None
Match item codes and unit prices against the product master	Fixed steps	Reads the product master CSV exported overnight
Check orders that don’t match the master	A person	None
Enter the order	Fixed steps (AI only when the screen changes)	Imports a CSV if there is an import function, and otherwise enters it on screen
Record the order number and report failures	Fixed steps	Reads the order number from the screen after entry

AI handles only reading purchase orders in different layouts, and what to do when a screen changes. Only orders that matched and orders a person checked are written to the core system. The use cases Read Excel purchase orders from email and enter them and Enter records into a desktop accounting app show the same flow. For entry after calls in a call center, see AI call centers and core systems: automating after-call work.

How this relates to rebuilding

Connecting through screens or files is not a substitute for rebuilding the system (modernization). It removes the manual re-entry around AI until the rebuild is done.

Even so, the connection work helps the rebuild:

• Material for requirements: which processes use which screens and files, in what order, is kept in the workflows and the ledger
• A small swap: once the rebuild provides an API, replace only the steps that operated screens with API calls. The steps for AI reading and human checks stay as they are

Frequently asked questions

Does this work with host terminal screens?

Anything that reads the screen and types on the keyboard can operate a terminal emulator too. At high volume, though, reading and writing the emulator’s screen text directly through an API, or file transfer on the host side, is faster and more reliable. Power Automate, for example, has actions that get and set text and send keys in terminal emulators through HLLAPI.

Do we need to tell the core system vendor?

Screen operation takes the same route as a person, but a maintenance contract or terms of use may have rules about automated operation or database access. Check with the vendor before you start, including whether the account used for automation needs a user license.

Is it safe to show core system screens to AI?

When AI reads a screen, a screenshot is sent to the provider of the AI model you chose. If the screen shows customer or transaction data, check the provider’s terms on whether what you send is used for training, and how long it is kept. Running on a dedicated PC or VM, so that other windows don’t appear on screen, also helps. Security summarizes how the main AI model providers handle your data.

Connecting with Kitewell

Descarty’s Kitewell is AI RPA that AI builds and AI fixes. It runs inside the same network as your core systems, and connects to those with no API through both screens and files.

• Screen operation: AI reads the screen and uses the mouse and keyboard to operate sales management and accounting software and dedicated clients with no API, on macOS and Windows. Operations that worked are remembered and repeated without AI while the screen stays the same
• File exchange: write an Excel list to a CSV in the core system’s import format (Shift_JIS available), and read the CSVs it exports. Server operations and file transfer over SSH, and API calls, sit in the same workflow
• Called from AI agents: Claude and ChatGPT can run workflows and approve steps through MCP (running and approving from ChatGPT needs a Business, Enterprise, or Edu plan). Kitewell opens the connection to the relay itself, so no port is opened in your network. The AI agent only calls workflows within the projects and permission you allowed, and never operates the core system directly
• Started from cloud services: a notification from any service that can send a webhook, such as an approval in kintone or a form submission, can start a run (on paid plans). It also arrives through the relay, so no port is opened
• People check before writing: a person reviews the screen before it is saved and approves. Send it back, and only that row is redone
• Passwords stay out of AI’s hands: core system passwords are referenced by name, and Kitewell types them in without showing the value to the AI
• Alerts when it stops: failures and pending approvals are sent to Slack, Microsoft Teams, email, and more. With projects synced through Dagu Cloud, a cloud console lists the runs on every computer, and alerts you when a computer you chose stops reporting for 10 minutes. Only run status is sent, never logs, parameters, or outputs
• Connections stay on record: each run keeps its logs and screenshots, and you can export a robot ledger to Excel
• Build and fix by conversation: describe what you want, and the assistant builds the workflow. When something stops, discuss the cause straight from the failed run’s screen

Under an enterprise plan, the computers that run workflows can be VMs or dedicated PCs in your own cloud, on your premises, or in a closed network. Licensing, team sync, and updates can all stay in your environment, and with in-house or local AI models nothing is sent outside. AI models that can read and operate a screen are limited, though, and small local models usually cannot operate one, so discuss which model to use in a closed network at the PoC stage. Desktop operation uses the screen, so it runs on a dedicated PC or VM whose screen is not locked.

To find out whether your system can connect, ask for the free legacy integration check. After looking at the screens, we tell you whether and how it can connect.

You can start by choosing one process where people still re-enter data into the core system, and testing it in a two-week PoC, quoted individually. If the agreed success criteria are not met, you pay nothing. See Pricing & PoC for details.

Summary

• Legacy systems remain at over 60% of the Japanese companies surveyed, and leave manual re-entry before and after AI
• The six challenges: getting data out, putting data in, screen design, reach, the spread of mistakes, and knowing what is connected where
• Choose in this order: API, files, reading the database, then screen operation. Mixing them in one process is fine
• Put a human check before anything is written to the core system
• With connections recorded in a ledger, a rebuild only means swapping screen steps for API calls

Sources

• IPA (Information-technology Promotion Agency, Japan): DX Trends 2025 (June 26, 2025; in Japanese). The state of legacy systems is in section 2.5 of the main report
• IPA: DX Trends 2026 (July 30, 2026; in Japanese). Challenges in preparing, managing, and sharing data are in section 3.8 of the main report
• Cloud Ace, Inc. (クラウドエース株式会社): survey on the use of AI agents (October 9, 2025; in Japanese)
• Anthropic: Computer use tool
• Microsoft: Terminal emulation actions reference