Legacy software modernization
Legacy software modernization, without stopping the business.
Old software nobody dares to change is a risk you carry every day. We take it over, record what it really does in automated tests, and replace it one part at a time while your team keeps working.
Photography is illustrative.
- We take on
- Ageing web apps, desktop and Access databases, spreadsheet processes, apps stuck on a builder platform
- First step
- A short, priced assessment that ends in a written plan and a fixed quote
- Approach
- Tests first, then replacement in stages, each switch reversible
- Pricing
- Each stage quoted before it begins. No open hourly meter
What we do
Legacy modernization services.
Legacy software is any system the business depends on that has become hard to change: the original developers have gone, the platform is out of support, nobody is sure what a change will break, or each new requirement takes months. Modernization makes it safe to change again. The work usually includes some of these:
- Taking over the code. Source control, a repeatable build and deploy, and a written map of how the system fits together.
- Tests around today's behaviour. So every later change can be checked against what the system did before.
- Upgrades. Moving an unsupported language, framework, database or server to a supported version.
- Staged replacement. Rebuilding the system a part at a time behind the same front door, so users switch over gradually.
- Data migration. Moving years of records to a new database with every record reconciled.
- Security hardening. Old systems often predate current practice: secrets in code, missing access checks, unpatched dependencies.
Rewrite or modernize
Why we rarely start with a full rewrite.
A full rewrite looks clean on paper. In practice the old system holds years of rules nobody wrote down, the business keeps asking for changes to it while the new one is being built, and nothing is delivered until the whole thing is finished. Many rewrites end up running late with both systems still alive.
Staged replacement avoids this. The parts that cause the most pain move first, each move is small enough to check and to reverse, and you can stop after any stage with a working system. A rewrite is a decision we make with you, for a stated reason, not a default.
How it works
Assess, make it safe to change, then replace in stages.
Every engagement is led by a senior engineer and runs through the same reviewed engineering process we use on our own software, including AI-assisted work under human review.
-
Assessment
A short, priced assessment of the software as it is: the code, the database, the servers it runs on, who depends on it and what breaks when it goes down. We talk to the people who use it, because the real rules of an old system are often in their heads rather than in any document.
You get A written report: what to keep, what to change, what to replace, in what order, with a schedule and a fixed quote for the first stage.
-
Make it safe to change
Before changing behaviour, we capture it: automated tests that record what the system does today, including the odd cases people rely on. We add source control, a repeatable build, and backups that have been restored, if any of those are missing.
-
Replace in stages
One part at a time moves to the new code while the rest keeps running. Traffic or users switch over a piece at a time, each switch can be reversed, and the old and new versions can run side by side until the results match.
-
Move the data and retire the old system
Data migrated with checks that every record arrived and still adds up, rehearsed before the real move. The old system is switched off only when nothing depends on it.
You get Software your team can change with confidence, and the notes to run it.
Timeline and pricing
How long modernization takes and how we price it.
Modernization is quoted, not listed. The assessment is bounded and priced up front, and it ends with a plan and a fixed quote for the first stage. Each later stage is quoted before it begins, so the programme can be paced to your budget and stopped after any stage.
What moves the price and the schedule: the size of the system and how many other systems depend on it, how much of its behaviour is documented or tested already, the volume and condition of the data, how much downtime is acceptable at switch-over, and any regulatory constraints on the data. Our published prices, for checking, fixing and looking after an app that already exists, are on the pricing page.
Proof
Systems the founding team has changed safely while they ran.
The founding team runs a production telehealth platform whose database has been changed migration by migration while clinical organizations used it every day (the count is below), and took a medicolegal assessment platform off the AI builder it started on onto an engineered system (built and working, not yet in paid use). Across the systems the founding team built and runs:
- 2,500+ database migrations in one production healthcare platform
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 940+ merged pull requests across the same codebases
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Before you modernize a legacy system.
Should we rewrite our legacy software or modernize it in stages?
Usually in stages. A full rewrite has to rediscover every rule the old system enforces, while the business keeps asking for changes to the old one, and it delivers nothing until the end. Replacing one part at a time delivers value sooner and can be stopped or redirected safely. A rewrite is right when the old system is small, or its platform can no longer run at all, and we will say so if that is your case.
How much does legacy software modernization cost?
Modernization is quoted, not listed, because the cost depends on the size and state of the system. The assessment has a fixed price agreed before it starts and ends with a fixed quote for the first stage. Each later stage is quoted before it begins, so you are never committed to the whole programme at once. Our published prices.
Will the business keep running during the modernization?
That is the point of working in stages. The old system keeps serving users while each part is replaced, every switch-over can be reversed, and the riskiest moves, such as the data migration, are rehearsed before they happen for real.
Nobody who built our system still works here. Can you still take it on?
Yes. That is the normal situation. We read the code and the database, watch how people use the system, and record its behaviour in automated tests before we change anything. Our AI-assisted engineering system helps map a large unfamiliar codebase quickly; an engineer checks what it reports before anything is decided.
What technologies do you modernize from and to?
We work from what you have: older PHP, .NET, Java or Rails applications, desktop and Access databases, and processes run on spreadsheets. We usually modernize towards TypeScript, Node and Postgres, or a current version of your existing stack when that is the cheaper path. If a system is in a language we should not take on, we tell you at the assessment.
How do you migrate the data safely?
With scripts that are rehearsed against a copy of the real data, checks that count and reconcile every record after each run, and a planned fallback if the checks fail. The real migration is the last rehearsal, not the first attempt.
Can you modernize an app that started on a no-code or AI builder?
Yes. Moving an app off a builder platform onto code you own is a modernization in miniature: capture what it does, rebuild the parts the platform did for you, migrate the data and switch over. Fix an AI-built app.
Tell us about the system you depend on.
What it does, what it runs on, who uses it, and what worries you about it. An engineer reads it.
Next sheet · A‑080