Plenty of businesses running critical operations, purchase orders, sales orders, inventory, still rely on ERP systems with character-based, terminal-style interfaces. On the surface, that looks like a dead end for automation. In practice, it isn't.
The Problem with Screen-Scraping
The default way most teams try to automate a legacy ERP is by simulating a human: opening a remote desktop session, taking a screenshot, running OCR to read what's on screen, then clicking and typing based on what the OCR engine thinks it saw. It works, until it doesn't.
- OCR accuracy degrades with font rendering, zoom level, colour profile, and session quality
- Every layer in the chain, remote desktop, screen capture, image recognition, is a new point of failure
- Small, unrelated environment changes can silently break the automation
A Better Access Layer: Direct Terminal Emulation
Most legacy ERPs weren't actually built around screen images. Underneath the desktop client is a standard terminal protocol, VT100, TN3270, or TN5250, that the client is simply rendering. Modern automation platforms can speak that protocol directly.
Instead of taking a picture of the screen and guessing what it says, the automation reads the terminal buffer as structured text. There's no OCR, no image tolerance, and no dependency on the remote desktop rendering correctly. The bot logs in as a named service account and follows the exact same navigation a human operator would, so audit trails and business rule enforcement stay intact.
What This Means in Practice
Removing the remote desktop and OCR layers doesn't change what the automation does, it changes how reliably it does it. Fewer moving parts means fewer 3am failures, and it means the case for automating a legacy system no longer has to hinge on replacing that system first.
If your team has written off automation because your core system is old, it's worth revisiting that assumption. The interface being unfashionable doesn't mean it's unreachable.