Most businesses running on legacy software know they should replace it. The system works, mostly. It's slow, sometimes. Nobody fully understands how it was built, always. And the person who built it left years ago.

The reason replacement keeps getting deferred isn't ignorance. It's that replacement feels risky and expensive, and the old system, for all its faults, keeps the lights on. The known problem is easier to live with than the unknown of a migration.

This guide is for businesses that have reached the point where the calculus has shifted, where the cost and risk of staying on the old system now outweighs the cost and risk of replacing it.

The legacy software problem, why businesses stay stuck

Legacy software creates a specific kind of organisational trap.

The system becomes load-bearing. People build their processes around its quirks. Reports are extracted in a particular way. Data entry has a specific sequence that only works if you know the undocumented rules. New staff are trained by tribal knowledge, not documentation.

Meanwhile, the software itself becomes harder to change. The original developer is gone. Nobody wants to touch the database schema because they're not sure what will break. The system was built for a version of the business that no longer exists, and the gap between what it does and what you need it to do keeps widening.

And the integrations problem grows. Your accounting software has changed. Your CRM has changed. Connecting modern systems to legacy software requires increasingly elaborate workarounds, CSV exports, manual rekeying, scheduled overnight syncs, that multiply opportunities for error.

The result is a system that costs more to maintain every year, creates more risk every year, and delivers less value relative to what modern tools could do. But the replacement project feels daunting, so it stays on the "someday" list.

Common legacy systems worth replacing: Access, FileMaker, old web apps, Excel-as-software

The systems we see most often in Australian businesses due for replacement:

Microsoft Access databases built in the late 1990s and 2000s. Access was a genuinely practical choice for many small businesses at the time, it allowed non-programmers to build something that worked. The problem is that Access doesn't work well with modern web interfaces, doesn't handle multiple concurrent users gracefully, and lives on a single PC or a shared network drive, which creates performance and reliability problems. Many Access databases haven't been properly modified in years because nobody feels comfortable touching them.

FileMaker (now Claris FileMaker) systems. FileMaker was widely adopted in Australian businesses, particularly in the 1990s and 2000s, and some organisations have built substantial operational systems in it. FileMaker is actually still actively maintained and sold, so it's a somewhat different situation from Access, but businesses running on very old FileMaker versions face real risks, and the platform's licensing model has changed enough that some businesses are motivated to move.

Old custom web applications built in the 2000s or early 2010s. These are often running on technology stacks that are now unsupported (older versions of PHP, Rails, .NET), lack modern security practices, and are impossible to maintain because the original code quality was poor. Sometimes these are documented; often they're not.

Excel as business software. This deserves its own category because it's so common. Spreadsheets have become operational databases at many businesses, there are customer records in spreadsheets, job tracking in spreadsheets, financial models in spreadsheets that drive real decisions. Excel is genuinely good at what it's designed for, but when a spreadsheet becomes the system of record for a business-critical process, you're one file corruption or accidental overwrite away from a serious problem.

Vertical market software that's been discontinued or orphaned. Industry-specific software that was acquired, stopped being maintained, or lost its developer support. The software keeps running until it doesn't, and there's no clear path forward.

Signs it's time to replace (not upgrade)

Some signs suggest the system needs modernisation; others suggest it needs replacement. Here's how to tell the difference.

Replace when:

• The underlying platform or technology is no longer supported (unsupported OS, discontinued database engine, deprecated language version)
• The business has outgrown the fundamental architecture, a single-user desktop application for a multi-user, multi-site business
• Integration with modern systems is impossible or requires so many workarounds that the workarounds themselves have become a maintenance burden
• The person who understood the system is gone and nobody can make changes confidently
• Security or compliance requirements can't be met within the existing system's constraints
• The cost of keeping the system running (workarounds, manual processes, risk management) exceeds the cost of replacement

Consider upgrading when:

• The underlying platform is still supported and maintained
• The core data model still reflects how your business works
• The issues are about the interface or workflow, not the fundamental architecture
• The cost of migration would primarily be recreating functionality you already have, with minimal new value

The honest answer is that most truly legacy systems, Access databases, old FileMaker builds, ten-year-old web applications, are replacement candidates. Upgrades are often good money after bad.

What modern replacement actually looks like

A modern replacement for a legacy business application is typically a web-based application that works in a browser, stores data in a proper database (PostgreSQL, MySQL, or similar), and can be accessed securely from anywhere.

This matters practically because:

• Multiple people can use it simultaneously without the file-locking problems of Access
• It works on any device, Mac, Windows, tablet, phone
• It can be accessed remotely without a VPN or remote desktop setup
• It integrates with modern APIs, accounting software, payment systems, communication tools
• It can be backed up properly, have its logs monitored, and be updated without disrupting operations

The design of the replacement should be driven by how your business works now, not how it worked when the original system was built. This is an opportunity, not just a migration. Many businesses discover during a replacement project that they've been working around the limitations of their old system for so long that they'd forgotten what they actually wanted the process to look like.

How AI has changed the cost of legacy modernisation

Legacy system replacement used to be among the most expensive categories of software project, because it combines the cost of building new software with the cost of understanding and replicating what the old system did.

AI development tools have materially changed the maths here.

The analysis phase, understanding what the legacy system does, documenting its behaviour, identifying edge cases, can now be assisted significantly by AI. Feeding code and database schemas into AI tools to generate documentation, identify patterns, and flag anomalies is substantially faster than doing it manually.

The build phase benefits from the same AI-assisted productivity improvements that apply to all software development. Complex data migration logic, transformation scripts, and validation code that would have taken weeks to write can be developed much faster.

The rough impact: a replacement project that might have cost $150,000–$250,000 a few years ago is often achievable for $50,000–$100,000 today, depending on complexity. This puts replacement within reach for businesses that would have deferred it indefinitely under old pricing. For a broader look at how AI tooling has changed development costs, see why custom software costs a fraction of what it did five years ago.

Migrating data: the part everyone underestimates

Every legacy replacement project involves data migration, and data migration is almost always harder than the initial estimate suggests.

The data in a legacy system accumulates years of inconsistency. Records that were entered before the validation rules existed. Fields that changed meaning over time. Duplicates that were never cleaned up. Data that was imported from another system and didn't quite fit. Foreign keys that reference records that no longer exist.

The process of moving data to a new system is really the process of confronting all of that accumulated messiness. You have to decide: clean it during migration, clean it after, or live with it in the new system.

Our strong recommendation is to invest in data quality before and during migration, not after. The cost of cleaning data in a new system, where you now have two systems to maintain while you're doing it, is higher than doing it up front.

A realistic budget for data migration is 20–40% of the total project cost for systems with significant data history. Skimping on this is one of the most reliable ways to turn a successful build into a problematic launch.

Specific things to budget for:

• A data audit of the existing system before scoping begins
• Transformation scripts to convert data from the old format to the new
• Validation to confirm the migrated data is correct and complete
• A parallel running period where both systems are live and can be compared
• A cleanup pass after initial migration for records that didn't migrate cleanly

Phased replacement vs big bang, how to reduce risk

There are two basic strategies for replacing a legacy system: replace everything at once (big bang), or replace it in pieces over time (phased).

Big bang replacement has the advantage of simplicity, you cut over on a date and the old system is retired. It has the disadvantage of requiring everything to be built and tested before you can get any benefit, and if something goes wrong at go-live, the stakes are high.

Phased replacement introduces the new system one module or workflow at a time. Users transition gradually, the old system is retired piece by piece, and risks are contained to each phase. The trade-off is that you're running two systems simultaneously for a period, which creates its own overhead.

For most small-to-medium business applications, we'd recommend a phased approach with a defined, relatively short total timeline, six to nine months for a full migration, not an open-ended "we'll get there eventually." The parallel running period should be as short as practically possible, because it's expensive and creates confusion. In some cases, a low-code platform can serve as a faster interim replacement for one module while the full custom build is underway, worth considering when the legacy system is causing the most pain in one specific area.

A clear cut-over date for each module, with proper data reconciliation before moving on, keeps the project from drifting.

What it costs in 2026

To be honest about the numbers:

Simple Access or FileMaker replacement (a small database with a handful of core screens, under 10,000 records, minimal integrations): $20,000–$45,000. This covers analysis, rebuild, data migration, and a brief parallel period.

Mid-complexity operational system (multi-user, several modules, integrations with accounting or CRM, moderate data volume): $45,000–$100,000.

Complex legacy system (years of business logic, significant data history, multiple integrations, compliance requirements, custom reporting): $100,000–$250,000.

These figures reflect modern development with AI tooling. The same projects five years ago would have cost 2–3x more. If you received a quote for legacy replacement a few years back and shelved the idea on cost grounds, it's worth revisiting.

The other cost to include in your calculation is the ongoing cost of staying on the old system: time spent on manual workarounds, risk of data loss or system failure, lost productivity from staff working around limitations, and the growing cost of keeping unsupported software running. Legacy modernisation has a return on investment, not just a price tag.

Code Workshop: legacy replacement in Australia

Code Workshop is based in Bowral, NSW, and we work with businesses across Sydney and regional Australia on custom software, including legacy system replacement. You can see the full range of what we build on our AI development services page.

We've replaced Access databases, migrated FileMaker systems, and rebuilt custom web applications that had outgrown their original architecture. We understand that the people who use these systems often have a complicated relationship with them, the old system is frustrating, but it's familiar, and the fear of losing something important in the transition is real.

We take that seriously. Our approach to legacy replacement starts with understanding the existing system properly before writing a line of new code.

If you're sitting on a system that needs replacing and haven't known where to start, a conversation with us is a good first step. We can give you an honest view of what's involved, what it would cost, and whether now is the right time.

Book a chat with us