Legacy ERP Automation in Australia: What Is Safe and What Is Not
A great many profitable Australian businesses run on an ERP installed a decade or two ago. It does the core job, everybody knows it, replacing it looks like a year of pain, and it has no interface of any kind. So the accounts team retypes, the warehouse keeps a parallel spreadsheet, and every report starts with somebody exporting something by hand.
You can automate a great deal around a system like that, and most of the genuinely safe wins involve never touching its screens at all. This page separates the low risk work from the high risk work, explains exactly how screen level automation fails on old thick client software, and makes the case that whatever you build should be sized against a date by which the system will be gone.
Realistic ROI
Four Things That Decide How This Goes
Legacy ERP work rewards a particular order of operations. Get the order wrong and you spend the most money on the most fragile part.
Reading is safe, writing is where the risk lives
Extracting data from an old ERP is comparatively low risk and delivers most of the value people are actually asking for: dashboards that do not require somebody to export at eight in the morning, reconciliations that run themselves, alerts when stock or debtors cross a line, and a clean feed into whatever newer systems the business has bought since. Writing back into the ERP is a completely different proposition, because a mistake changes real records inside the system of record. Do all the reading work first, prove it, and only then discuss whether anything genuinely needs to be written.
Old systems have more doors than their owners think
On premise ERPs from that era were built when reporting meant direct database access, so many of them sit on a standard database with an ODBC or SQL route the vendor supports for reporting. Most have a report writer that can schedule output to a file. Many can print to a file, which is an ugly but entirely serviceable data feed. Quite a few have a documented import format left over from the original migration. Before anybody proposes driving the screens, all of those need to be checked, because each one is cheaper to build and dramatically cheaper to keep alive.
Screen automation on a thick client is brittle in specific ways
Old ERP interfaces are often keyboard driven, run inside a remote desktop or published application session, and were written when screen sizes were fixed. That makes them harder for a robot to read reliably than a modern web page, and it makes small environmental changes, a different resolution, a slower session, a new login banner, into breakages. Worse, the breakage frequently does not raise an error. A field that has shifted one row means the robot types a value into the wrong box and saves it happily. This is not a controversial view even among the vendors selling the tooling: UiPath’s own documentation notes that where a program has a changing layout or attribute values that shift between sessions, the software cannot predict it and the automation has to be pointed at elements by hand (checked August 2026). Every design decision has to be aimed at making a silent misfire impossible or immediately obvious.
Automate to a horizon, and plan the exit in parallel
The uncomfortable question with an unsupported ERP is not whether it will be replaced but when, and building elaborate automation around it without answering that question is how businesses end up paying twice. Decide on a rough horizon, size the automation spend against it, and start the replacement analysis at the same time rather than after. The useful part is that the work overlaps: documenting what data lives where and which processes depend on it is the first half of a migration study, so the effort carries forward instead of being thrown away.
What Can Actually Be Automated Around an Old ERP
Roughly in order of risk. The first four touch nothing inside the ERP and are where most businesses should start and often finish.
Layer 1
A nightly extract of the tables or reports that matter, landed somewhere modern where anything can query it without touching the ERP. This single step removes an enormous amount of manual work, because most of the exporting people do by hand exists to feed a spreadsheet or a report. It also protects the ERP, since queries run against the copy rather than the live server. Where the vendor permits a read only database connection this is straightforward. Where they do not, a scheduled report writer output to a watched folder does the same job.
Layer 2
Once the data is out, the reporting stops being an ERP problem. Sales, stock, debtors, job costing and margin can be assembled and refreshed on a schedule, and cross system reconciliations, ERP against the bank feed, ERP against the online store, ERP against the warehouse spreadsheet, can run every night and only speak up when something disagrees. This is usually the fastest measurable win in the whole programme and it carries essentially no risk to the ERP itself.
Layer 3
With a daily copy of the data, exceptions can be detected and pushed to the people who need them: stock about to run out, a customer over a credit limit, a job that has not been invoiced, a purchase order overdue against its promise date. The old ERP will not do this and probably never will, and it is one of the highest value things you can bolt alongside it. Send the alerts somewhere people already look, and give each one a clear owner and a clear action rather than adding to the general noise.
Layer 4
Order status pages, delivery notifications, statement delivery, quote follow up and supplier portals can all be built from the extracted data without the ERP being involved beyond providing the nightly feed. Customers get a modern experience, the ERP carries on doing what it does, and if the ERP is replaced later the customer facing layer survives the change because it was never coupled to it. This is often the piece that makes the whole programme worth funding to a board.
Layer 5
Pushing ERP data into the CRM, the payroll system, the ecommerce platform or the warehouse tool one way, with the ERP as the single master, is usually achievable through the same extract. One way is the important word. Two way synchronisation with an old ERP is where projects go badly, because reconciling conflicts between two systems that both think they are right is a permanent job rather than a build. Decide which system owns each piece of data and publish in one direction only.
Layer 6
Only when data genuinely has to go back into the ERP, and no import route, database write permission or vendor option exists, does driving the screens make sense. Built properly it uses its own named login, validates the screen before every entry, reads the saved record back and compares it to what was intended, stops the entire run on any mismatch rather than skipping ahead, logs every action with values and timestamps, and waits for a human to approve anything financial. Built improperly it is the fastest way to fill your system of record with wrong numbers.
Common Legacy ERP Requests and the Safer Way to Meet Them
| Task | Traditional | Safer approach | Notes |
|---|---|---|---|
| Daily sales and margin reporting | Someone exports and rebuilds a spreadsheet | Nightly extract feeding a live dashboard | No writing, no screen driving, and it usually removes the single largest block of manual admin in the business. |
| Stock levels shown on the website | Updated by hand a few times a week | One way feed from the nightly extract | Publish from the ERP outward. Never let the website write quantities back into a legacy system. |
| Keying supplier invoices | Typed into the purchasing screens | Check for an import format before automating keys | Many old ERPs accept a formatted import file left over from their migration tooling. Ask the vendor in writing. |
| Customer statements and reminders | Generated and emailed manually | Built from extracted debtor data outside the ERP | The chasing happens entirely outside the fragile system, which is what makes it reliable. |
| Creating new customer records | Retyped from the CRM | Import route first, supervised screen entry as last resort | If it must be screen driven, validate on screen, read the record back, and stop the run on any mismatch. |
| Month end reconciliation | Two days of comparing printouts | Nightly automated comparison with an exception list | Differences surface daily while they are still traceable, instead of as a pile on the last working day. |
| Posting journals or payments | Entered by finance staff | Prepare automatically, let a person post | Anything that moves money keeps a human approval step regardless of how good the automation is. |
| Two way sync with a newer system | Nobody quite knows which is right | Make the ERP the single master and publish one way | Bidirectional sync against a legacy ERP is a permanent conflict resolution job, not a project with an end date. |
Where Legacy ERP Automation Goes Wrong
Writing directly into the vendor database
It is technically possible and it is almost always a mistake. The application enforces rules, calculations, sequence numbers and audit records that a direct database write bypasses entirely, so the data ends up internally inconsistent in ways that only show up weeks later in a report or a period close. It will also void your support agreement, which matters most on the day you have a genuine unrelated problem. Treat database access as read only unless the vendor has explicitly documented a supported write path, and get that in writing.
Support agreements and licence terms
Check what your maintenance contract and licence actually permit before anything is built. Terms in this area vary enormously between vendors and get revised without much fanfare, so read your own agreement rather than assume the general case. The four things to look for are whether an additional non human user is permitted and what it costs, whether support is declined in any environment where automated access is present, whether the terms restrict use of the interface to a person, and whether they forbid letting anything else sign in with a staff member’s credentials. This is a short written question with a large downside if skipped, and occasionally the reply comes back with a paid integration option or a supported export the client never knew about, which changes the entire shape of the project.
Remote desktop sessions and screen environments
Old ERPs are often reached through a published application or remote desktop session, and screen driven automation inside one of those is sensitive to things nobody thinks of as changes: a different screen resolution, a session that times out, a slower than usual login, a new banner, a printer prompt. Give the automation its own dedicated session with a fixed configuration that nobody else uses, wait for specific elements to appear rather than using fixed pauses, and handle the known interruptions explicitly. Most reliability complaints about this kind of automation come down to environment drift rather than the automation itself.
Period close, month end and financial year behaviour
Legacy ERPs behave differently at period boundaries: screens lock, posting dates are rejected, extra prompts appear, batch jobs run and the system slows to a crawl. An automation tested in the middle of a quiet month will meet all of that for the first time on the worst possible day. Test explicitly against a closed period and against end of month load, decide deliberately whether the automation should pause during close, and make sure whoever runs finance knows how to stop it.
Silent drift rather than a clean failure
The dangerous failure is not the one that stops, it is the one that carries on. A shifted field, a changed tab order or a new confirmation dialogue can mean the automation continues entering data into the wrong places while reporting success. Insist on validation of the screen before each write, verification of the saved record afterwards, an immediate hard stop rather than skipping the record, and a daily reconciliation that would catch a run gone wrong. If a proposal does not describe those four things, it is not finished.
Building a permanent dependency on a system you intend to retire
The more capable the automation around a legacy ERP becomes, the harder the eventual replacement gets, because every one of those connections has to be rebuilt. Keep the automation loosely coupled: extract to a neutral copy and build everything else against the copy, so that replacing the ERP changes one component rather than fifteen. Write down what depends on what. Then, when the migration finally happens, you already have the dependency map, which is the document most migration projects lack and most badly need.
How Yes AI Approaches Old On Premise ERPs
We look for every supported door first
Vendor questions in writing, the report writer, scheduled exports, printing to file, documented import formats and any permitted read only database connection. Screen automation is only proposed once those have genuinely been ruled out, and you get the findings either way.
We build the read only layer before anything else
A nightly extract into a neutral copy, then reporting, reconciliation and alerting built against that copy rather than against the ERP. It carries almost no risk, it usually removes the largest block of manual work, and it survives the day the ERP is finally replaced.
We will tell you to plan a migration instead
If the system is unsupported, if the vendor has stopped releasing, if it runs on a machine nobody is allowed to patch, or if it is blocking several improvements at once, we will say that the money is better spent on the replacement study. That is a smaller engagement for us and it is the right advice.
Nothing screen driven is built without a maintenance arrangement
Where screen automation is genuinely the only route, it is quoted with monitoring, response times, a named internal owner and a tested manual fallback. Without that arrangement agreed we do not build it, because an unwatched robot in a system of record creates bad data rather than an obvious outage.
From Locked In System to Working Data
Five steps. The first three deliver most of the value and touch nothing inside the ERP.
Inventory the doors and the dependencies
What the ERP holds, what already leaves it and how, which spreadsheets exist alongside it, which people export what by hand, and what the vendor and licence terms permit. Written up as a dependency map that is also the starting point for any future migration.
Build the extract and the neutral copy
A scheduled extract into a copy that everything else reads from, so the ERP is queried once a night by one thing rather than continuously by many. Validated against known totals before anybody builds on top of it.
Deliver reporting, reconciliation and alerts
Dashboards, cross system reconciliations and exception alerts built against the copy. Low risk, quick to prove, and typically the point at which the manual exporting habit stops.
Decide, deliberately, whether anything needs writing back
If data must return to the ERP, exhaust the import routes and vendor options first. Where screen automation is the only path, it gets its own login, screen validation, read back verification, a hard stop on mismatch, full logging and a human approval gate on anything financial.
Set the horizon and keep the exit open
A named owner, a maintenance arrangement, a tested manual fallback, and an honest view of how long the ERP has left. Everything stays coupled to the neutral copy rather than to the ERP, so a replacement changes one component instead of the whole estate.
Related Reading
Automate Software With No API
The full decision ladder, from supported interface down to a screen robot.
RPA for Australian SMEs
Honest economics on what volume of manual work justifies a robot.
Legacy System Integration
Connecting older business systems without replacing them first.
Data Migration Services
Getting decades of history out cleanly when the replacement happens.
Replatforming and Cutover
Planning the switch so the business keeps trading through it.
Automated Reporting and Dashboards
What the nightly extract makes possible on day one.
FAQ
Get the Data Out Before You Decide Anything Else
Book a call. We look at what your ERP will and will not let out, tell you which of the safe layers would remove the most manual work, and give you a straight view on whether the money is better spent automating around it or planning its replacement.
All discussions held in confidence. Australian-based consultants.