The system works. It's just stuck.
Stuck on one machine. Stuck on an unsupported version of Windows. Stuck in a FileMaker or Access database that one person built fifteen years ago and that nobody else fully understands. Stuck in a version of NAV that hasn't seen a patch since the previous decade.
Every business I talk to in this situation knows they need to do something. The harder question is what. Rebuild from scratch? Migrate to a cloud platform? Wrap it in an integration and buy time? Or keep supporting it until something forces the decision?
There's no universal answer. But there is a way to think through it that avoids the most common and most expensive mistake: jumping to a full rebuild before you understand what you're actually working with.
The common situation
The businesses that call us about legacy systems tend to have one or more of the following:
- A FileMaker, Access, or custom desktop application that runs on a single machine or a network share — not accessible remotely, not integrated with anything modern
- A Microsoft Dynamics NAV or older Business Central installation that's out of support, on-premise, and running on hardware that's due for replacement
- A NetSuite or similar platform that was configured years ago and has drifted so far from the standard setup that upgrades break things
- A custom system built by a developer who no longer works there — no documentation, no source code access, just a running binary and a backup schedule someone set up in 2017
The system still does its job. The problem is everything around it: remote access is painful or impossible, integrating it with modern tools requires workarounds, and any time something breaks there's nobody who fully understands the internals.
Your four options
1. Keep and support the current system
Not always the wrong answer. If the system is stable, the workflows around it are mature, and the business isn't under pressure from remote work or integration demands, "keep it running and maintain it" is a legitimate choice. It's the lowest disruption option and often undervalued.
What this requires: someone who understands the system well enough to fix it when something breaks, a backup and recovery process you've actually tested, and a realistic view of when this option stops being viable. Systems age. Hardware fails. Vendors end support. "Keep it running" is a strategy with a timer on it.
2. Migrate data to a cloud platform
Move the data and the workflows to a modern SaaS platform that handles your use case — Xero instead of MYOB or NAV, a modern job management platform instead of a legacy desktop system, Business Central cloud instead of on-premise NAV.
This works well when the existing system's core function maps reasonably well to what a modern platform offers. It does not work well when years of customisation have made the existing system significantly different from what any off-the-shelf product provides.
The migration itself is usually 80% data and 20% configuration. The 80% is the hard part. Source data that doesn't map cleanly to the target schema. Historical records in formats the new system doesn't understand. Custom fields that have no equivalent. A clean migration requires auditing the source data first, not after.
3. Rebuild as a modern web application
Build a replacement from scratch on a web-native stack. Clean break from the legacy system. The new application is browser-based, accessible from anywhere, integrates with modern tools, and can be maintained by any competent developer rather than someone who specialises in the legacy platform.
This is the highest effort option and the one most often chosen for the wrong reasons. "The old system is messy" is not sufficient justification. "We've mapped every business process and the old system can't be adapted to support them" is.
A full rebuild is appropriate when: the existing system's architecture genuinely can't be extended to meet current needs; the platform is end-of-life with no viable migration path; or the cost of maintaining and workarounding the existing system exceeds the cost of replacement over a realistic timeframe.
4. Integrate without replacing
Keep the legacy system doing what it does well and build integrations that connect it to modern tools. An old on-premise system with a database you can query can be wrapped with a REST API. An Access or FileMaker backend can serve data to a modern web frontend via ODBC or a data API. An on-premise NAV instance can push transactions to Xero via a middleware layer.
This approach is underused. It's often faster, cheaper, and lower-risk than a full replacement — especially when the legacy system has solid business logic that would take months to replicate in a new platform. You extend the life of the system while eliminating the parts that cause the most friction.
5. Move one module at a time
The strangler fig pattern: migrate functionality incrementally, one module at a time, while the legacy system continues running. Start with the piece causing the most pain. Build the replacement for that module, prove it works, then move to the next. The old system gets smaller over time until it can be retired.
This is slower than a full rebuild but significantly lower risk. Every step is in production and validated before the next begins. If priorities change or budget runs out, the partially migrated system still functions. You're not gambling on a single go-live date.
When not to rebuild everything
The full rebuild option gets chosen too often, too early, before the business understands what it's actually asking for.
Rebuilding a legacy system means replicating every business rule, every edge case, every workflow that people have built their daily processes around — and then migrating years of historical data on top of that. The list of things the old system does that nobody thought to document is always longer than expected.
Before committing to a full rebuild, ask: does an off-the-shelf platform now cover most of what this system does? If yes, migration is almost always faster and cheaper. Can we extend the existing system with integrations to remove the main pain points? If yes, integration buys time and may be enough. Is the rebuild driven by a genuine technical limitation or by a desire for something cleaner? The latter isn't a good enough reason on its own.
The businesses that fare best with legacy modernisation are the ones that do the discovery work first, understand what they're replacing in full, and then choose the lowest-risk path that achieves their actual goals.
Risks nobody talks about upfront
Missing source files. The application runs but nobody has the source code. The developer who built it left without handing it over. The original files are on a hard drive somewhere, maybe. If source code is unavailable, rebuild or replacement becomes the only option — you can't maintain or extend what you can't read.
No documentation. This is the norm, not the exception. The system does things that aren't written down anywhere. The only documentation is the behaviour of the running application and the memory of the people who use it. Discovery takes longer than planned, every time.
Hidden business rules. The system enforces rules nobody remembers deciding on. A validation that stops certain records being created. A calculation that applies a rate adjustment for a specific customer category. A workflow that triggers a follow-up only under certain conditions. These surface after go-live, when users encounter the new system not behaving the way they expected.
Old reports and templates. The reports that finance runs at month end. The invoice template that matches what clients expect. The compliance reports that the system generates. These are almost never factored into initial scoping and almost always take longer to replicate than anticipated.
Staff relying on manual workarounds. The system has a limitation, so staff developed a process around it. That process became habit and then policy, informally. When the new system removes the limitation, the workaround breaks — and nobody thought to document it because it wasn't in the system.
A process that actually works
Regardless of which path you end up taking, the starting point is the same: understand what you're working with before you decide what to do with it.
Discovery. Talk to every person who uses the system. Not just to understand what it does, but to understand how they actually use it, what they work around, and what would break their day if it disappeared. This takes a few days to a week for a typical system. It saves months of post-launch surprises.
Data review. Extract and audit the data. How much is there? How consistent is it? Are there years of accumulated quality problems that need cleaning before migration? What data structures exist in the source that have no obvious equivalent in the target? You can't plan a migration without this.
Workflow mapping. Document the actual workflows — not as the system was designed to work, but as it's currently used. These are different things. The documented workflows become the acceptance criteria for whatever comes next.
MVP rebuild or staged migration. Start with the highest-value, most contained part of the system. Prove the approach works on something real before expanding. The first piece in production teaches you more about the problem than any amount of planning.
Staged cutover. For critical systems, don't cut over everything at once. Migrate one user group, one location, or one module at a time. Keep the old system available in read-only mode for a period after cutover so staff can reference historical data while they adjust.
The businesses that get legacy modernisation right are rarely the ones who move fastest. They're the ones who map the problem thoroughly before writing a line of code.