Not every business with a legacy software problem needs to throw it away and start again.

Sometimes the system you have — old as it is — contains years of accumulated business logic. The data model reflects how your operation actually works. Your staff know it. The edge cases are handled. What's broken isn't the software, it's the technology running underneath it: an unsupported PHP version, a Windows-only runtime, a database that predates cloud hosting.

That's a different problem from "this system is wrong." And it has a different solution.

If you've already decided you need a full rebuild, the replace legacy software guide covers that. This post is for businesses that have something worth keeping — and want to figure out how to bring it forward.

Upgrade or replace: how to tell the difference

The honest answer is that most businesses get this wrong in one direction or the other. Some rebuild when they didn't need to, spending significant money recreating functionality they already had. Others upgrade when they should have rebuilt, doing expensive remediation on a system that was structurally broken from the start.

The clearest signal for an upgrade is this: if the system's data model still reflects how your business works, that's worth preserving. A database schema that's been shaped by years of real use — the relationships, the tables, the way data is structured — that's genuine intellectual property. Rebuilding it from scratch is risky, because the knowledge encoded in that structure often isn't documented anywhere.

Conversely, if the system's business logic is wrong — not just old, but actually incorrect — then you're not preserving value, you're preserving errors. A replatform will carry those errors forward with you.

The other honest thing to say is that familiarity creates a bias. Systems feel more valuable than they are because people are used to them. If you're weighing up upgrade versus replace, it's worth getting an independent technical view rather than relying on the people who've been living with the system.

What a legacy software upgrade actually looks like

An upgrade means keeping what's valuable and fixing what isn't. In practice, that takes a few different forms.

The most common one we see is a technology refresh on an old web application. PHP 5, early Rails, older ASP.NET — stacks that are no longer supported, increasingly hard to host, with security patches long since stopped. The application logic is fine. The interface works. The problem is purely that the underlying technology has aged out. A replatform moves the codebase to a current stack, cleans up the worst of the accumulated technical debt, and adds modern security practices. The system looks and behaves much the same. The internals change substantially.

A related scenario, very common in Australian manufacturing, professional services, and logistics businesses, is a desktop application that needs to move to the web. Someone built an Access database or a VB6 application in the late 1990s or early 2000s. It's been running since. It works, mostly. But it only runs on one machine, or via remote desktop on a Windows XP virtual machine, or it requires a specific printer driver nobody's had for a decade.

Moving this to the web preserves the data and the core logic. Staff can access it from any device. Multiple users can work in it simultaneously. You get proper backups and a hosting environment that's actually maintained. This is usually faster and cheaper than a full rebuild, because the underlying process model is sound — you're just changing where it lives.

A third scenario that's often underestimated: adding an API layer to a system that currently doesn't talk to anything. Data leaves the system via CSV export and enters your accounting package via manual import. Someone re-keys jobs from one system into another every morning. Adding an integration layer — connecting the existing system to Xero, your CRM, your logistics platform — doesn't touch the core application at all. It's often the highest-value, lowest-risk modernisation work available, and it's frequently faster than people expect.

There's also UI modernisation: the system works fine, the back end is solid, but the interface looks like 2009 because it was built in 2009. Staff find it confusing. New hires complain. Nothing works on mobile. If the back end has clean, consistent interfaces (or can be given them), replacing the front end while leaving the data layer alone is a cost-effective way to get a dramatically better result without the risk of a full rebuild.

How the process works

Legacy modernisation takes longer in the discovery phase than a greenfield build. You're working out what the existing system actually does before you can decide how to carry it forward — and old systems rarely document themselves.

That means reading the code, mapping the database schema, documenting the business rules embedded in the logic, and identifying what's genuinely worth preserving versus what can be removed or cleaned up. This phase surfaces surprises: features nobody uses, logic that's never triggered, dependencies that weren't obvious. It's unglamorous work, but skipping it is how modernisation projects go wrong.

Once you understand what you have, you can design what you're moving to — which parts of the codebase are preserved, which are rewritten, what the new hosting environment looks like, how the data migration will be handled.

For most projects we favour incremental delivery: one module or workflow at a time, with the old and new systems running in parallel for a defined period before cutting over and retiring the old component. This keeps risk contained and means users see progress early rather than waiting for a big-bang launch.

What AI has changed about the cost

Legacy modernisation used to be expensive partly because of the analysis burden. Understanding what an old system actually does — thoroughly enough to replicate or extend it — took a lot of senior developer time. Reading undocumented code, reverse-engineering business logic, mapping a database schema with no ERD: slow, careful, expensive work.

AI tools have materially compressed this. Feeding legacy code into AI tools to generate documentation, identify patterns, map dependencies, and flag edge cases is substantially faster than doing it manually. The analysis still has to happen; it just takes less time.

The build phase benefits from the same productivity improvements that apply across all software development now. The practical effect is that modernisation projects that would have been quoted at $150,000–$200,000 a few years ago are often achievable for $60,000–$120,000 today, depending on complexity. The same shift is happening across the industry — see why custom software costs a fraction of what it did five years ago for more on that.

What it costs in 2026

Rough ranges, honestly given:

Technology refresh (replatforming an old web app to a current stack, minimal new features): $25,000–$60,000. The main variable is the quality of the original codebase. Clean, well-structured code is cheaper to replatform than a tangle.

Desktop-to-web migration (moving an Access or VB6 application to the browser): $35,000–$80,000. Data migration complexity drives the range. A clean data model migrates cleanly; years of accumulated inconsistency costs more to untangle.

API and integration layer (connecting an existing system to external platforms): $15,000–$40,000.

UI modernisation (replacing the front end while keeping the backend): $20,000–$50,000.

Full replatform with new features (updating the stack and adding meaningful new capability): $60,000–$150,000.

These figures assume an Australian team, proper discovery, and no offshore outsourcing. If you've received quotes significantly below these, ask specifically what's included in the discovery phase.

Code Workshop: legacy modernisation in Australia

We're based in Bowral, NSW, and we work with businesses across Sydney and regional Australia on custom software — including legacy system upgrades and modernisation.

We've replatformed old web applications, migrated desktop systems to the web, added API layers to closed systems, and helped businesses figure out whether what they have is worth upgrading or whether a clean rebuild is the better call. Sometimes that assessment leads to a modernisation project. Sometimes it leads to a recommendation to start fresh. We'll tell you which, and explain why.

If you've got a system that's working but holding you back, a conversation is a reasonable place to start.

Book a chat with us