Skip to content
StitchOps

Legacy and on-prem systems

Automate the systems that predate APIs.

The systems that run the business are often the ones nobody can integrate. SAP GUI, a green-screen session, a thick client from an acquisition, an on-prem console with no vendor left to call. Modernising them is a multi-year project; the work they hold is due this week.

What the rest of the stack cannot reach.

StitchOps runs those systems the way an operator would, from an agent on a worker VM inside your network. Desktop, terminal, file, and browser steps in one workflow. Deterministic replays, credentials from the vault, and a log of every step, without touching the system itself.

Desktop and terminal

Windows UI Automation, image and OCR fallbacks, and terminal sessions, for the clients and consoles with no web front end.

Inside the network

The agent runs on a dedicated worker VM in your environment, outbound TLS only. The legacy system never needs to be exposed.

Mixed workflows

Read from the mainframe, write to the portal, file the export. One workflow spans the old system and the new.

Built to survive change

Named elements with multiple locator tiers and vision fallbacks. When something does break, the run stops with evidence for a quick repair.

How it works with your stack.

Step 1

Pick the bottleneck

The screen a person sits in every day because nothing else can reach it.

Step 2

Scope a proof of value

Systems, inputs, evidence, and confirmation gates, agreed in the workflow audit.

Step 3

Deploy

The agent on a worker VM next to the system, outbound TLS only. Credentials into the vault.

Step 4

Run, then connect the rest

The discovery session becomes a saved workflow. Each adjacent system is a sub-workflow.

How it runs

Described once. Replayed every time.

Tell Stitch the task, review the typed steps, and save it. The agent runs it on a worker VM in your environment with a vaulted credential, and logs every step.

See the platform →
acme-dealers / offboard-closed-apps
Run
Triggerdirectory.user.disabled
Browser · openvendor-portal.example.com
Browser · login{{secrets.vendor.admin}}
Browser · find user{{input.email}}
Gateconfirm deactivate
Evidencecapture step 5
6 steps · validated against registry · v14

What you can finally automate.

Post transactions into SAP GUI from an approved spreadsheet

Query a mainframe session and write the results to a data table

Provision or remove accounts in an acquired application's console

Export a report from a thick client on a schedule and file it

Keep an on-prem directory in step with the identity platform

Governance

Ask for it in plain language.

Claude, ChatGPT or Copilot can run these from your existing assistant. The model picks from typed tools; the agent owns the credentials and stops for confirmation on anything destructive.

Connect your assistant →
acme-dealers / AI assistants
Run
Offboard j.doe@example.com from the three portals SCIM doesn't cover and show me the evidence.

I found a saved workflow for this. Running it on worker-01.

tool call

workflow_offboard_closed_apps

{ "email": "j.doe@example.com" }

Confirmation required

Step 5 deactivates the user in vendor-portal. This cannot be undone by the workflow.

ConfirmCancel

completed in 5.2s

3 portals · 6 steps · evidence: step_05.png, step_11.png, step_17.png

Done. The user is removed from all three portals. Evidence is attached to run_01j8k.

Ask your assistant…

Start with one workflow that never had an API.

Fifteen minutes on your top three manual processes. We tell you which one to run first.