Making a legacy system work with AI when you have no idea how it works

Every company has one: the system from 2009 that runs everything and that nobody fully understands. Now someone wants AI to use it. You don't have to understand all of it. You need to understand the five things people actually do with it

1. Find out what it really exposes

Ignore what the docs say (if there are docs). Check what's actually there:

• An API, even an old SOAP one. Look for a ?wsdl URL
• A database you can read from
• Scheduled exports, like a CSV that lands somewhere every night
• Only a web UI. Open your browser's dev tools, go to the Network tab, click around, and watch which requests it sends

2. Write down the real tasks

Sit with the people who use it and list what they do every day, like "look up a customer's last order" or "check if an invoice is paid". That list is your whole scope. Anything not on it doesn't exist yet

3. Put a small, clean API in front of it

Don't point AI straight at the old thing. Build a thin layer that does one job per endpoint, takes simple inputs and returns plain JSON:

GET /customers/{id}/last-order
GET /invoices/{number}/status

Inside, it does whatever ugly thing the legacy system needs: the SOAP envelope, the weird date format, the field called CUST_FLG_2. Outside, it looks normal

4. Translate the weirdness

• Error code -1043? Return "invoice not found"
• Fields with cryptic names get real names. Write down what each one means. That data dictionary is honestly the most valuable thing you'll make
• Dates, money and status codes get one consistent format

5. Protect the old system

Legacy systems often fall over under load they were never built for, and an AI calling your API in a loop is exactly that load. Cache what doesn't change often, rate limit everything, and set timeouts so one slow call doesn't freeze the rest

6. Then hand it to AI

Once the clean API works, wrapping it as MCP tools is the easy part: one tool per endpoint, with a description that says when to use it. Serve the data dictionary as a tool too, so the model can look up what a field means instead of guessing

Things that will save you

• Read-only first. Writes come later, one at a time, each with a person who owns it
• Record real responses and test against those, so you're not poking production
• Keep the legacy system's own permissions. If a user can't see a record in the old UI, they shouldn't see it through AI either