The system still works. That is exactly why replacing it all at once is the riskiest thing you could do.
Most legacy system modernisation in Australia is not prompted by a failure. It is prompted by drag. The system still runs. It still produces the numbers. But it only runs on one machine under someone's desk, or the vendor stopped developing it in 2016, or the Access database that started as a stopgap now holds fifteen years of job history, or one staff member is the only person who knows the order the screens have to be used in. Nothing is broken. Everything is slower than it should be, and quietly riskier than anyone has said out loud.
Drawn AI works with Australian businesses in that position. Liam and Jacob started the business in 2024 after enough years of working around systems like these — Liam in retail operations management, Jacob in mining operations. We work from Melbourne, Victoria and from Queensland, remotely, across the country — so we are used to operations, including regional ones, where the office and the site are a long way apart and a system outage is not a minor inconvenience.
The important decision is not what to build. It is how to get there. Almost every failed modernisation we have seen described took the same route: build a complete replacement in parallel, run it for a year or two, then switch everything over on a weekend.
The strangler-fig approach: put a new system beside the old one and move one function at a time — first reporting, then a form, then a workflow — until the old system has nothing left to do. Each step is small enough to reverse.
Usually the safest first move. Copy the legacy data out to a modern database and build reporting and analytics on the copy. Nothing in the old system changes, and people stop touching it just to get a number out.
Old software often has no usable export. There are almost always other ways in: a direct database read, an ODBC connection, scheduled report files, or parsing printed output. We work out which of these your system allows before anything else is planned.
Sometimes the right answer for this year is not to replace it at all, but to connect it to the systems around it — accounting, payroll, CRM — so it stops being an island while you plan a proper replacement.
Quoting, job costing, scheduling, and the contractor and compliance registers common in mining and resources operations — each rebuilt as custom software fitted to your process and cut over on its own, with the legacy system still running behind it.
Rules that exist only in a compiled application or in one person's head get written down and tested. This is often the single most valuable artefact of the whole exercise.
We find out what the system does, who depends on it, and what it would cost you if it stopped for a week. That last question sets how cautious the plan needs to be.
We map the processes running through it and separate the rules that matter from the habits that grew around the software's limitations. Mapping the process first is what stops you rebuilding those limitations in a new system.
We prove we can extract the data — completely and repeatably — before anything is designed. If extraction is not possible, that changes the whole plan, and it is better to know in week one.
Each function moves on its own schedule, with the legacy system still available. If a piece does not work, you fall back to the old one that day. No weekend switchover of everything at once.
The old system is decommissioned only when nothing depends on it, with an archived, readable copy of its data kept. We keep refining what replaced it as people use it.
Because they run for a year or more before delivering anything, while the business keeps changing underneath them. Requirements drift, budgets run out mid-build, and the switchover concentrates every risk into one weekend. Incremental replacement gives you working improvements early and a fallback at every step. It is slower on paper and safer in practice.
It is a common situation and rarely fatal. You generally do not need the vendor — you need the data and an understanding of the rules. Both can usually be recovered from the database, the reports and the people who use the system daily. What you should do straight away is confirm you still have a licence key and a working backup.
Usually, yes. Options include reading the underlying database directly, an ODBC or file-level connection, scheduled report output, or parsing print files. We test extraction early, before any design work, because it is the one thing that can change the entire approach. Occasionally some history is unrecoverable, and we say so plainly.
We work on a monthly subscription — minimum three months, billed monthly, 30 days' notice — rather than a fixed project price. Incremental work suits that model, because you can start with one piece, see what it delivers, and decide how fast to go. You get a monthly figure before committing to anything.
Less than a full replacement, because the old system stays available while each piece moves. Staff learn one new screen at a time instead of an entire application in a week. Expect time from whoever knows the system best during discovery and mapping — that is the main demand on your team.
Yes. We are based in Melbourne, Victoria and in Queensland, and work Australia-wide, including regional operations. Most modernisation work — discovery, mapping, extraction testing, review sessions — is done remotely. For a first conversation, email outreach@drawnai.app or use the contact page.
A first conversation costs nothing and usually ends with a clearer idea of what is worth building — sometimes that answer is “not yet”, and we will say so.
No lock-in templates. Built around you.