Legacy System Modernisation
Replace your core system without betting the company on a rewrite.
The application that runs your operation is old, and the two people who understand it would like to retire. We replace it a slice at a time behind a facade, so each release takes some risk away and the business never has to stop.
What you end up with
- Take the key-person and end-of-life risk out from under your core system
- Stop paying for licences, hosting and workarounds just to stand still
- Get back to shipping a change in days, without a month of regression testing first
- Keep the business running the whole way through, with no cut-over weekend
Most projects start with a fixed-price discovery, so you have a scoped plan and an estimate in hand before you commit to a build.
Overview
Why we do not recommend a ground-up rewrite
Legacy systems stick around because they work. An Access database runs the warehouse, and a VB6 or WinForms application sits on every terminal on the shop floor. A PHP or Java monolith took ten years to absorb the business rules and nobody wrote them down anywhere else. The trouble is that the vendor stopped supporting the platform years ago and nothing modern can talk to it without a nightly CSV export. Nobody wants to be the one who touches it, so the instinctive answer is a ground-up rewrite. In our experience that is the option most likely to run over by years and get cancelled before it goes live.
We do it in stages. An assessment works out what the system does today and which parts are worth keeping. Usually a fair amount of it turns out to be unused. Then we put an API in front of the old system and peel capabilities off one at a time into new services, migrating the data with reconciliation reports and running old and new side by side until the new path has proved itself. Sometimes the right answer is a targeted refactor or a re-platform with no rewrite at all, and the assessment says which.
What's included
The kinds of work this covers.
- 01
Modernisation assessment
Analysis of the code, the data and the dependencies, interviews with the people who use and maintain the system, and a recommendation you can act on. It will be one of refactor, re-platform, rebuild in stages, or leave it alone.
- 02
Strangler-fig migration
A facade in front of the legacy system routes traffic to new services one capability at a time. Each release replaces one slice, and each slice can be rolled back on its own if something looks wrong.
- 03
Data migration and reconciliation
Schema redesign, cleansing, mapping and migration scripts you can run again and again, with reconciliation reports that show every record accounted for. We rehearse the migration many times before the final run.
- 04
Re-platforming and refactoring
Moving .NET Framework to current .NET, upgrading Java and PHP estates, putting the application in containers and moving it to the cloud, and refactoring wherever the code is worth keeping.
- 05
Replacing desktop and Access/VB6 applications
Web-based replacements for WinForms, Access and VB6 tools, designed with the operators who use them every day. That makes adoption much less of a fight.
- 06
Parallel running and safe cut-over
Old and new running side by side with output comparison, feature flags per user group and a written rollback path. The aim is a go-live that nobody outside the project notices.
Is it right for you?
A good fit if
- A system the business depends on runs on an unsupported platform, or on one or two people
- Changes take months and every release breaks something in a different module
- You need the old system to talk to modern tools and there is no clean way to do it
- A previous rewrite stalled, or got cancelled half-way through
- The licence, hosting and support bills for the old estate go up every year
How we approach it
The steps between a first call and go-live.
Assess and decide
Three to six weeks mapping what the system does, what data it holds, what it connects to and where the risk sits. You get a roadmap with options, an order of work and estimates, plus a recommendation you can take to the board.
Stabilise and wrap
Get the legacy system into source control and CI, add monitoring, and put an API layer in front of it. New work can then start without anyone touching the fragile core.
Migrate in slices
Replace one capability at a time, starting with whichever is most valuable or most at risk. Each slice is released, checked against the old path while both run, and in daily use before the next one starts.
Decommission and hand over
Final data migration, the old system switched off, documentation and training for the people who will run the new one. Then either a support arrangement with us or a hand-over to your own team.
Deliverables
What you'll have at the end.
- Assessment and roadmap with options and estimates
- The legacy system under source control, CI and monitoring
- API facade and new services, with source code you own
- Data migration scripts, reconciliation reports and the results of each rehearsal
- Parallel-running and cut-over plan with rollback steps
- Documentation, training and the old estate switched off
Typical stack
The tools we tend to use for this.
Questions
Questions about this service.
How do you decide between a rewrite, a re-platform and a refactor?
The assessment answers that. Well-structured code on an old platform often only needs re-platforming. Tangled code that holds valuable rules is a candidate for staged replacement behind a facade. Occasionally a small system is best rewritten outright. We recommend whichever option carries the least risk while still meeting the goal, even when a more interesting option is on the table.
How long does modernisation take?
Programmes typically run six to eighteen months. You see benefit from the first slice, usually within two to three months, and that is the point of doing it in stages.
How much does it cost?
Assessments typically run £15k to £40k. Programmes vary a lot. Most of the ones we take on fall between £100k and £500k spread over phases, and each phase is scoped and estimated on its own, so you can pause or stop between them without losing what has already shipped.
Will the business have to stop during migration?
No. The old system keeps running until each new piece has proved itself alongside it. Cut-overs happen one capability at a time, and most users only find out because the screen looks different.
We have no documentation and the original developers have left. Is that a problem?
It is normal, and it describes most of the systems we see. We recover the understanding from the code, the database and the people who use it every day, and we write characterisation tests that pin down what it does today. Then we can be sure the replacement matches, including the odd behaviour someone has been relying on.
Related services
Industries
- Manufacturing & IndustrialShop-floor, quality and planning software connected to your machines and ERP.
- Logistics & Supply ChainDispatch, tracking, warehouse and carrier systems that keep goods moving.
- Professional Services & B2BClient portals, engagement tools and internal platforms for firms that sell expertise.