Legacy Software Migration and Modernization
Moving a system off a dying platform without changing what it computes.
The problem this solves
The system works. That is exactly what makes it hard to replace. It has years of business rules baked into it, some of them written down and some of them only in the code, and it is running on a language version, a database, or a framework that is out of support. Your options look like living with the risk or paying to rebuild something that already does its job.
There is a third option, and it is the one we do: move the system onto a supported foundation while changing nothing about what it produces. Same inputs, same outputs, same numbers, new platform underneath.
We have done exactly this four separate times, at four clients and in four different technology stacks. A vendor-held revenue platform with no build environment and no servers of its own. A field-reporting application on a web platform a decade past end of life. A federal environmental-compliance system on a dead runtime. And an inherited line-of-business system whose original author was long gone. Different industries, different languages, one job.
How we prove nothing changed
Claiming a migration is behavior-preserving is easy. Proving it is the work, and it is the part most rewrites skip.
On a recent federal environmental-compliance platform, we moved a system that had been in service for over a decade off an end-of-life runtime and rewrote its entire data layer. To prove the rewrite was faithful, we ran the old system and the new system against the same database and diffed the results: 243 compliance calculations across four instrument types, with zero regressions. That comparison ran before anyone was asked to approve a cutover.
It shipped with Active Directory single sign-on and a tested rollback plan, because a migration you cannot reverse is not a migration, it is a gamble.
That is the standard we hold on this work. Nothing is called finished because it looks finished. It is finished when it has been driven end to end against real data and the evidence has been produced.
What we actually do
- Assessment first. We read the system before we touch it, and tell you what is genuinely at risk versus what merely looks old. Some systems do not need migrating. We will say so.
- A design you approve. You see the plan, the sequence, and the rollback before any code changes.
- Runtime and framework replacement. Moving off unsupported language versions, databases, and platforms.
- Data layer rewrites. Replacing the part that talks to the database without disturbing the part that computes.
- Behavior verification. Old versus new, run side by side against one dataset, differences enumerated rather than assumed.
- Authentication and access. Bringing systems onto single sign-on and current access control.
- A rollback that has been tested. Not a rollback that exists on paper.
The engagement is supposed to end
A system becomes legacy when the rules that change most often are buried in the part that is hardest to change. We build the opposite way wherever the work allows it: the rules live in data, not in code. Rate tables, validation rules, pick lists, thresholds, and workflow steps go into tables or configuration your own staff can edit, and a small engine reads them.
The practical effect is that the next time your process changes, you change a row instead of hiring a developer. It is also the approach that has held up longest across the systems we have built, in defense cataloging, optical telecom, and forensic appliances alike.
This is also why the work is priced by milestone rather than by the hour. An hourly arrangement pays for time on site, which quietly rewards a system that keeps needing attention. A milestone is paid when a defined thing is finished and handed over, working, documented, and yours. We would rather be the last engineer a system needs than a permanent line on your budget.
What we work in
SQL, PHP, JavaScript, C#/.NET, Java, and C/C++, including embedded and cross-compiled targets. On the data side, Microsoft SQL Server, PostgreSQL, MySQL, and T-SQL.
If your system is in something not on that list, tell us anyway. Reading unfamiliar code and working out what it does is most of this job.
Who this is for
Businesses running something they cannot afford to break and cannot afford to keep as it is. Typically a system that predates the current team, has no original author available, carries real compliance or financial consequences if it computes the wrong answer, and is now blocking an upgrade, an audit, or an acquisition.
Common questions
How do you prove the new system produces the same results as the old one?
We run both systems against the same database and compare the output row by row. On a recent federal compliance platform that meant diffing 243 calculations across four instrument types and showing zero differences before anyone approved a cutover. If a difference does turn up, it gets explained and signed off rather than absorbed quietly.
Nobody here understands the old system anymore. Is that a problem?
It is the normal case, not the exception, and it is the specific thing we are good at. Four separate times we have taken over a business-critical system that nobody inside the company still understood, and every one of them went back into service. Reading unfamiliar code and working out what it actually does, including the parts that were never documented, is the majority of this work.
Can this happen without taking the system offline?
Usually yes. The migration is staged so the old system keeps running while the new one is built and verified beside it, and the cutover itself is short and reversible. A tested rollback plan is part of the delivery, not an optional extra.
What if the assessment says we do not need to migrate?
Then we tell you that. Some systems look old and are fine. We would rather lose the project than sell you a rewrite you did not need, because the referral is worth more than the invoice.
Talk to us about your system
Every engagement starts with an assessment and a design you approve before anything changes. If you would rather talk it through first, that is free and there is no obligation attached to it.