Legacy software modernisation
We bring older business systems up to date one part at a time, so the business keeps working throughout and you can stop after any stage with a system that is better than before.
How a system changes in stages
The new part runs beside the old one and takes over an area at a time. Users keep one system throughout, and you can stop after any stage.
-
Today
One address for usersEverything runs on the old code.
-
After stage 1
One address for usersThe first area has moved. Users notice nothing.
-
After stage 2
One address for usersMost of the system is on the new platform.
-
Finished
One address for usersThe old code is switched off and removed.
The problem with old software is rarely that it is old
A fifteen-year-old system that does exactly what the business needs is an asset. It becomes a problem when the things around it move on: the vendor stops issuing security fixes, the hosting provider retires the server, the browser drops a feature the screens rely on, and developers who know the technology become hard to find. At that point every change is slower and riskier than the one before.
Modernisation deals with those specific problems. It does not have to mean replacing everything, and in our experience it usually should not.
Why we work in stages
The alternative to staged modernisation is the big-bang rewrite: build a complete new system, then switch over on a single day. It is attractive on paper and frequently goes wrong. The old system has to be maintained in parallel for the whole project. Years of business rules buried in the code are rediscovered only when the new system gets them wrong. And nothing is delivered until everything is delivered.
Working in stages avoids all three. Each stage replaces one part of the system and goes live on its own. The new part runs alongside the old one and takes over gradually, so a problem affects a small area and can be reversed. You pay for one stage at a time and can reorder or stop the programme as priorities change.
Where we usually start
The first stage is chosen for its value, and three candidates come up again and again:
- Whatever is out of support. A database or framework version that no longer receives security fixes is a known and growing risk. See our end-of-support dates for where each version stands.
- Whatever hurts users most. One slow screen or one unreliable overnight job can colour people’s whole view of a system.
- Whatever blocks everything else. Without an automated build and a set of tests around key behaviour, every later stage is harder, so that groundwork often comes first.
What it looks like in practice
For a typical system built on .NET Framework and SQL Server, a programme might run like this: bring the database onto a supported version; put an automated build and release pipeline in place; move the most frequently changed parts of the application to current .NET behind the existing interface; then replace the user interface a section at a time. Each of those is a self-contained piece of work with its own outcome.
If you are not yet sure whether the system should be modernised at all, a code audit answers that question at a fixed price.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss staged modernisation 0800 433 7990What modernisation usually involves
- Getting back into vendor support
- Moving databases, frameworks and servers onto versions that still receive security fixes.
- Replacing the front end
- Swapping desktop screens, Web Forms pages or an old JavaScript framework for a current web interface, screen by screen.
- Moving to modern .NET
- Migrating .NET Framework code to current .NET, starting with the parts that change most often.
- Untangling the database
- Moving business logic out of stored procedures and triggers where it is holding you back, and fixing the queries that slow everything down.
- Automating build and release
- Replacing manual deployments with a pipeline that builds, tests and releases the same way every time.
- Moving off ageing hosting
- Migrating from an on-premises server or an old hosting contract to the cloud, with a rehearsed cut-over.
How we stage the work
Assess and map
We establish what the system does, what it depends on and where the risk and the cost of change are concentrated.
Protect existing behaviour
Automated checks are added around the behaviour the business relies on, so we know immediately if a change alters it.
Pick the first slice
We choose one part with a clear benefit: something out of support, something users complain about, or something that blocks other work.
Build the new part alongside the old
The replacement runs next to the existing system and takes over a little at a time. If it misbehaves, traffic goes back to the old part.
Retire the old part and repeat
Once the new part has carried the full load without incident, the old code is removed and we move to the next slice.
Each step is priced before you commit to it
You can stop after any step and keep what it produced. Nothing depends on agreeing to the next one.
-
A first call
Free20 minutes
You describe the system and what prompted the call. We say whether we can help, and if we are not the right people we say that too.
Arrange a call -
A code audit
£1,950 fixed1 to 2 weeks
A written report on the condition of the system, its risks and what to do first. It is yours whatever you decide, and the fee is credited against any work that follows.
What the audit covers -
A first piece of work
Fixed priceAgreed in writing
Usually the priority items from the audit, or one defined package. Scope, price and acceptance checks are agreed before we start.
How fixed price works -
Ongoing support, if you want it
From £450 a monthCancel with 30 days' notice
A monthly plan covering faults, updates and small changes. The code, accounts and documentation stay yours throughout.
Support plans
A good fit when
- The system does its job but runs on technology that is out of support or hard to hire for.
- Changes that should take days take weeks.
- The business cannot stop using the system while it is replaced.
- You want to spread the cost and see results at each stage.
Probably not for you if
- The system no longer matches how the business works; new technology under the wrong process will not help.
- A packaged product now does the job well enough.
- The system has only a year or two of useful life left; maintenance is the cheaper course.
Questions we are asked
Why not just rewrite the whole system?
A full rewrite means paying for a second system while still running the first, with no benefit until the new one is complete, and rewrites routinely miss behaviour that nobody remembered to specify. Replacing the system in stages delivers improvements sooner and lets you stop whenever the remaining work is no longer worth it.
How long does modernisation take?
Each stage is typically a matter of weeks to a few months. The whole programme depends on the size of the system and how far you want to go. We plan and price one stage at a time.
Can a modernisation stage be done at a fixed price?
Often, yes. Once the assessment has removed the main unknowns, a stage with a defined outcome, such as moving a database to a supported version, suits a fixed price.
Will users have to learn a new system?
Only where the interface changes, and then gradually. Much modernisation happens underneath and is invisible to users apart from the system getting faster and more reliable.
Do you use AI tools in modernisation work?
Yes, for analysing unfamiliar code, generating tests around existing behaviour and translating code between framework versions. Every change is still reviewed by an engineer and proven by tests before release.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.