- There are three broad approaches: rewrite it all, wrap it in something new, or replace it piece by piece.
- Full rewrites are the riskiest. They take longer than planned, and the old system keeps changing while you build.
- Replacing one piece at a time, with old and new running side by side, is slower to start and much safer to finish.
- The data move deserves its own plan, with rehearsals and checks against the old numbers.
- Some old systems should be left alone. Stable, rarely changed and well understood is not a problem.
What "legacy" really means
Legacy doesn't mean old. Plenty of old software is fine. A system becomes legacy when it holds the business back.
It shows up in familiar ways. A change that should take a day takes a month. Only one person, or one outside contractor, can touch it. It runs on a server or operating system that no longer gets security updates. It can't share data with newer tools, so people retype. Customers and remote staff can't reach it.
Usually it's a combination. A custom order system from the 2000s. An Access database that became the company's backbone. A desktop program from a vendor that stopped selling it. The system still does its job. Everything around it has moved on.
Three ways to modernize
Rewrite it all
Build a complete replacement, then switch over on a set date. It's the most tempting plan because it promises a clean break.
It's also the riskiest. The old system holds years of rules nobody wrote down. The rewrite takes longer than planned. Meanwhile the business keeps asking for changes, so the old system keeps moving while the new one chases it. When the switch day comes, everything changes at once for everyone.
Joel Spolsky called rewriting from scratch the single worst strategic mistake a software company can make. That was in 2000, about commercial software, but the reasoning holds for internal systems too. Old code is ugly partly because it has absorbed years of fixes for real problems.
Rewrites make sense when the system is small, the rules are well understood, or the old platform truly can't be kept alive.
Wrap it
Leave the old system in place and build around it. A modern screen on top. A connection that lets other software read and write its data. A portal for customers that pulls from it.
Wrapping is fast and low risk. It solves the "nobody can reach it" problem without touching the core. It doesn't fix an unsupported server or the single expert, so it's often a first step rather than the end.
Replace it piece by piece
Pick one part of the work. Build the new version of just that part. Route that work to the new system while everything else stays in the old one. Then the next part, and the next.
Martin Fowler named this the strangler fig, after a vine that slowly grows around a tree until it stands on its own. Microsoft's architecture guidance describes the same pattern. Over time the old system does less and less, until it can be switched off.
It's slower to start. You need a way for old and new to share data while both are running. In return, every step is small, each one delivers something useful, and you can pause between them without being stuck halfway.
For most mid-size companies, this is the approach we'd start with.
Running old and new side by side
The safest switch is the one where nobody notices a switch.
For a while, both systems process the same work. Orders go into both. The new system calculates prices, schedules or invoices, and someone compares its results to the old one. When they match day after day, the team starts trusting the new one. When they don't, you've found a hidden rule before it cost anything.
This takes discipline. Decide upfront what "matching" means, who checks, and how long the parallel run lasts. A few weeks of clean comparisons is usually enough for a given piece of work.
Keep a way back. Until the old system is retired, you should be able to send the work back to it if something goes wrong with the new one.
Moving the data
Data migration is where modernization projects quietly go over budget. Plan it as its own piece of work.
- Profile it first. Look at what's actually in the tables. Old systems collect duplicates, blank fields, codes nobody remembers and dates stored as text.
- Decide what moves. Not every record from 2009 needs to come along. Active records move. Old ones may go to a read-only archive that stays searchable.
- Translate, don't just copy. Old status codes, customer types and pricing rules need to map to the new system's meaning, not just its fields.
- Rehearse and reconcile. Run the move on a copy. Compare counts and totals: customers, open orders, balances. Fix the gaps and run it again until the numbers agree.
When to leave it alone
Not every old system needs replacing. Some should be left exactly as they are.
A system that rarely changes, does its job reliably, runs on supported software and doesn't block anyone is not a problem. It's an asset. The same goes for a system that's due to be retired anyway when a contract ends or a division is sold.
In those cases, the right move is often small. Back it up properly. Document how it works while the expert is still around. Put a connection on it so other systems can read its data. Then spend your budget where the pain is.
The honest test: what would get better if you replaced it? If the answer is "it would be newer," wait.
Questions to settle before choosing
Before anyone picks an approach, a few answers shape everything else.
- Is there a hard deadline? An unsupported server, a vendor ending a contract or a license that won't renew. A deadline can make wrapping or a fast move of the riskiest piece the only sensible first step.
- Who knows how it works? One person, a retired contractor, nobody? The less anyone knows, the more a side-by-side run matters.
- What does it connect to? List every system that sends it data or takes data from it, including the nightly export someone set up in 2014.
- Could off-the-shelf software do the job now? Twenty years ago there may have been nothing to buy. Today there might be. Our guide on custom or off-the-shelf helps you check.
- What should be different afterward? Not "newer." Faster quotes, remote access, no retyping, a second person who can make changes. Write it down. It becomes how you judge every step.
Where to start
If you're going piece by piece, the first piece matters. Look for work that is painful today, used often, and fairly self-contained. Quoting, customer intake and reporting are common first steps because they can run on the new side while orders and billing stay put.
Avoid starting with the part everything else depends on. The core record, often customers or orders, usually moves later, once the team has seen a few smaller pieces work.
Our guide on scoping a custom software project covers how to size that first release.
What most guides miss
The expert is the project's most important person. The person who kept the old system alive knows which strange rules matter. Treat them as a partner, not a risk to work around. Their time is worth protecting.
Freeze changes to the old system, gently. Every change made to the old system during the project has to be made twice. Agree that only urgent fixes go into the old one while the new piece is being built.
Retire things on purpose. Projects stall when the old system never quite gets switched off. Set a date for each retired piece, archive its data, and turn it off. The savings and the relief only arrive then.
Security is often the real deadline. An unsupported server or operating system can force the timeline. Find out early whether that's your case, because it changes what you do first.
How we do it
We start with a free intro call and an honest look at whether the system needs replacing. When it does, we usually go piece by piece, working alongside the people who know the old system, running old and new together until the numbers match. Then we stay on to keep it running. More on our custom software work.
