Systems integration
Legacy modernisation for the system nobody wants to touch
Every organisation has one: old, critical, poorly understood, and holding the business together. Modernising it is a risk — and so is leaving it alone.
The situation
Working, until the day it is not
Legacy systems are rarely a problem because they have stopped working. They are a problem because changing them, staffing them or connecting them has become too hard.
- Changes take months, or are refused outright
- One or two people understand it, and both are near retirement
- It cannot be connected to anything built in the last decade
- It runs on an operating system or framework no longer supported
- Nobody is confident what would break if it were changed
- The documentation is out of date, missing, or was never written
What it covers
What modernisation covers
There are several routes and they are not equivalent. The assessment decides which applies before anyone commits to a rewrite.
Assessment
What the system does, what depends on it, what the real risk is, and what each option would cost. Frequently the answer is less drastic than expected.
Encapsulation
Putting an API in front of the existing system so modern software can use it, without changing the system itself.
Incremental replacement
Moving functionality out piece by piece behind a stable interface, so the business is never waiting on a single large switch.
Re-platforming
Moving to supported infrastructure without rewriting the application, where the risk is the platform rather than the code.
Rewrite
Where it is genuinely warranted — and it is warranted less often than it is proposed.
Knowledge capture
Documenting the behaviour and business rules while the people who know them are still available.
How we work
How modernisation runs
Incrementally, with the system working throughout. A big-bang rewrite of a poorly understood system is how modernisation projects fail.
Understand it
Establish what the system actually does, including the undocumented behaviour other systems and people have come to rely on.
Stabilise and wrap
Put an interface in front of it so new work can proceed without waiting for the old system to be replaced.
Replace in slices
Move functionality out a piece at a time, verifying each against the original before the old path is retired.
Retire
Switch off the legacy system only once nothing depends on it and the evidence says so.
Outcomes
What you are left with
- A system that can be changed at the pace the business needs
- Business rules documented rather than held by two people
- Modern systems able to connect to what was previously closed
- Supported infrastructure, with security patches available
- Risk reduced in stages rather than concentrated in one switch
- A defensible plan for the parts not yet modernised
Platforms and tooling
What we work with
Legacy
- COBOL
- VB6
- Classic ASP
- .NET Framework
- Delphi
- Access
- AS/400
Target
- .NET
- Java
- Node.js
- Python
- React
- Containers
Platform
- Azure
- AWS
- Docker
- Kubernetes
- CI/CD
Named as platforms we work with, not as formal partnerships.
Common questions
Questions we are usually asked
Almost always incrementally. A rewrite requires knowing exactly what the current system does, and if that were true it would not be a legacy system. Incremental replacement lets you verify each piece against the original and stop if the value is not there.
Yes, and that is the common case. Behaviour can be established from the code, the data and observation of what it actually does in use. It takes longer than working from documentation, which is why the assessment stage exists.
Sometimes that is right, and we will say so. A stable system doing a well-defined job may not be worth touching. The question is whether you can still get security patches, still hire people who can maintain it, and still connect the things the business now needs.
By not switching anything off until the evidence says nothing depends on it. Running old and new in parallel and comparing behaviour finds the undocumented dependencies that no amount of planning would have surfaced.
Usually, because incremental replacement means the system keeps running while pieces move. That is one of the strongest arguments against a single large cutover.
Longer than a rewrite proposal will claim, and it is spread across the work rather than concentrated in one release. The assessment gives you a scoped view of each option so the decision is made with real numbers.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Mainframe modernisationMoving off hardware and languages that are getting hard to staff.
- Data migrationMoving data between systems without losing its history.
- Systems integrationMaking the systems you already own talk to each other.
- Cloud servicesMoving to cloud, or making an existing cloud estate behave.
- Application development and maintenanceBuilding it, then keeping it running and current.
- Operational systemsThe systems that run the day-to-day work of the business.