Insights · 5 min read
Modernizing old software is not a rewrite, it is a phased migration. Here's how to replace pieces, protect the data, and keep the business running.
By GGP Editorial
Legacy system modernization sounds like a rewrite, and that is usually the first mistake. The business still has to run while you modernize it, which means you replace pieces in phases, keep the old and new running side by side, and cut over only when the new one is proven. Do it that way and the project survives contact with Monday morning.
We have done this for financial and property systems where the existing software was years old and nobody on the team fully understood it anymore. The pattern is always the same: do not rewrite everything at once, treat the data as its own project, and keep a rollback path for as long as you can.
A big-bang rewrite feels clean. You imagine a fresh codebase, no legacy decisions, no workarounds. The problem is that the old system encodes years of business rules that nobody wrote down. Taxes, discounts, settlement quirks, edge cases that exist because one specific client needed them in 2019. A rewrite throws all of that away and then discovers it one bug at a time, usually in production, usually at month-end close.
I have watched a rewrite of an accounting module drag on for more than a year because every new version was missing a rule someone only remembered when the numbers did not tie out. That is not a technical failure. It is a scoping failure, and it is avoidable.
The other reason rewrites fail is time. While the rewrite is going on, the old system still has to change, because the business still has to change. Now you are building two systems at once, and the new one is chasing a moving target. That is how a nine-month rewrite becomes a three-year project nobody will admit to starting.
The workable approach is to carve the system into pieces and migrate them one by one. Pick a piece with a clean boundary first, like a reporting module or a payment export, and move that to the new stack. Leave the rest running. Once the new piece has been stable for a few weeks, move the next one.
This is sometimes called the strangler pattern, because the new system slowly replaces the old one the way a vine covers a tree. The unglamorous truth is that it requires running two systems in parallel for a while, with a routing layer in front. That costs more in the short term and saves the project in the long term.
The routing layer is where the effort goes. You need a way to send some requests to the old system and some to the new one, split by customer, by feature flag, or by data range. We build that as a thin gateway, often Nginx in front of a small routing service, so the business can turn features on gradually instead of switching everything on a Friday and hoping.
The code is only half the project. Moving years of data from an old schema to a new one is where modernization projects quietly die. The old data has duplicates, missing fields, and values that made sense years ago and no longer do.
Here is what usually goes wrong, and how we handle it:
| Migration risk | How we handle it |
|---|---|
| Duplicate records | Dedupe with a rule set the business signs off on, not a guess |
| Missing fields | Backfill from other tables or mark explicitly instead of leaving nulls |
| Broken relationships | Rebuild keys in a staging copy and verify before any cutover |
| Silent data drift | Run old and new in parallel and diff the outputs |
The last row is the important one. Run both systems on the same day of real data and compare the results. Differences will appear, and almost none of them will be obvious ahead of time. Fix them while you still have the old system as the source of truth.
For us, a modernization project is a series of small cutovers, not one big launch. We keep the client's team in a shared group, hold overlapping hours for the markets that need it, and write down every decision so a rule nobody remembered does not get lost a second time. Communication happens in English, and we keep Portuguese speakers available for clients who prefer it.
The new system usually lands on Java with Spring Boot, with MySQL or a managed database behind it and Redis where we need speed. The stack matters less than the sequence. Replace in pieces, protect the data, keep the rollback, and the business keeps running while the old system quietly disappears.
Tell us what you are building and where you are today. We typically reply within 24 hours.
