Legacy systems
The system that will outlive all of us, and has no API.
Somewhere in your organisation is an application written before APIs were a category. It runs something load-bearing. Nobody wants to replace it, nobody can integrate it, and a person re-keys data out of it every day.
Re-keying, in both directions
-
Sign in, often twice
A domain login for the machine, then an application login for the system. Sometimes a third for the terminal session.
-
Navigate by codes
Transaction codes and menu numbers, remembered by the person who has done it for eleven years. There is no URL to bookmark and no breadcrumb.
-
Read the screen, retype the data
Out of the green screen, into the spreadsheet, into the modern system. Or the reverse. The data crosses by hand because nothing else crosses it.
-
Be the integration
When that person is on leave, the job does not happen. This is the real cost, and it is rarely on any risk register.
An integration layer you do not have to earn a rewrite for
- Reads what is on the screen as structured text, including terminal-rendered screens.
- Drives the keyboard path a person would take: fields, transaction codes, submits.
- Extracts and delivers into a modern system by webhook or file.
- Asserts before acting: confirm the expected screen appeared before typing into it.
- Runs unattended, so the process no longer depends on one person being at their desk.
This is not modernisation. It is a bridge, and it is usually the only option that gets funded this decade.
Being realistic about this one
Web-fronted systems work best
If the legacy application is reachable in a browser (even a thin web-to-host bridge, even an intranet page wrapping a terminal) we can drive it. A true thick client installed only on specific desktops is a different problem, and we will tell you if that is what you have.
Assertions matter more here than anywhere
Legacy screens fail in confusing ways: a stale screen, a partial write, a session that silently dropped. Every run should assert that the expected screen is present before it types, because typing into the wrong screen is worse than not running at all.
Read-only for the first month
Old systems often lack the transaction safety you would want before letting an agent write into them. Run read-only extractions first, verify them against what a human gets, and only then consider writes.
The honest failure mode
If the application is only reachable from one machine on one desk, the automation inherits that constraint. The usual answer is running the runtime on that machine or alongside it, which is a deployment conversation we should have early.
The succession-planning argument
The strongest case for automating a legacy system is rarely the hours. It is that one person knows how to do it, and eventually they will not be there.
Send us the screen.
We’ll tell you whether it is drivable before you spend anything.