For businesses running an on premise ERP the vendor stopped developing years ago

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.

Book a Legacy ERP Assessment (03) 9003 0111

Realistic ROI

Read first

Most of the safe value is in getting data out

Reporting, reconciliation, alerting and feeding downstream systems need no writing back and carry very little risk

Nightly

Is fast enough for most legacy reporting needs

Real time is the expensive requirement. A nightly copy answers the majority of what people actually ask for

Pick a horizon

Automate to a date, not forever

Decide roughly how many more years the ERP has and size the spend against that, rather than against an open ended future

Two projects

Run the automation and the replacement study together

The data mapping needed to automate around the system is most of the analysis a migration will need later, so it is not wasted

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.

A reporting copy

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.

Dashboards and reconciliations

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.

Alerts and exceptions

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.

Customer and supplier facing layers

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.

One way feeds into newer systems

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.

Controlled screen automation

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.

FAQ

Our ERP is twenty years old and the vendor barely supports it. Can it be automated at all?

Usually yes, and more easily than people expect, because systems of that era were built when reporting meant direct database access. Many sit on a standard database with a read only connection the vendor permits, most have a report writer that can schedule output to a file, and a surprising number can print to a file, which is a perfectly usable data feed. Any of those gets data out safely without touching a screen, which is where the majority of the value is. Writing data back in is a separate and much more careful conversation.

What is the safest thing to automate first?

A nightly extract into a neutral copy, and then reporting, reconciliation and alerting built on top of that copy. It touches nothing inside the ERP, it cannot corrupt a record, it can be validated against totals you already trust, and it usually removes the single biggest block of manual work in the business, which is people exporting things by hand to build spreadsheets. It also has the useful property of surviving a future ERP replacement, because everything you build reads the copy rather than the old system.

Can you write data back into a legacy ERP?

Sometimes, and it should always be the last option considered. The order to work through is a documented import format, then any supported vendor route or paid custom option, then a database write only where the vendor has explicitly documented one, and only then screen level automation. Where screen automation is genuinely necessary it must validate what is on screen before entering anything, read the saved record back and compare it against what was intended, stop the entire run on any mismatch, log every action, and hold anything financial for a human to approve.

Should we just replace the ERP instead?

If it is unsupported, if the vendor has stopped releasing, if it only runs on a machine nobody is allowed to patch, or if it is blocking several improvements rather than one, then yes, and we will say so rather than sell automation around it. If it genuinely does its core job well and the only real complaint is that it will not talk to anything, automating around it is a sensible decision for a defined period. The mistake is spending heavily on automation around a system you have already privately concluded is on its way out, because you will pay for the same connections twice.

Can we do both, automate now and migrate later?

That is usually the right answer, and the two efforts overlap more than people assume. Documenting what data lives where, which processes touch it and what depends on the ERP is the first half of any migration study, so the analysis is not wasted. The important design rule is to keep everything loosely coupled: extract to a neutral copy and build reporting, alerting, customer facing layers and downstream feeds against that copy. When the ERP is finally replaced, you change one component and the rest keeps running.

How much maintenance does this need?

It depends entirely on which layer you build. A scheduled extract and the reporting built on it is comparatively stable and needs occasional attention when the underlying data changes shape. Screen level automation is a different matter, because it is coupled to an interface controlled by somebody else and to the environment it runs in, so vendor updates, session changes and process changes all generate work. Screen automation is quoted with an ongoing arrangement covering monitoring and response, and we do not build it without one, since an unwatched robot in a system of record produces bad data rather than an obvious outage.

What about the spreadsheets everyone keeps beside the ERP?

Take them seriously, because they are documentation of everything the ERP does not do. Before automating anything, collect them and work out what each one exists for: a report the system cannot produce, a calculation it gets wrong, a status field it lacks, or a process that predates somebody who left. Some can be replaced by the reporting layer immediately, some describe a genuine gap that needs a small system alongside the ERP, and a few turn out to be the real requirements list for the eventual replacement. They are the cheapest research available and almost nobody reads them.

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.