Infrastructure & Longevity
Legacy System Modernisation
We take on the projects most agencies decline. Auditing inherited codebases, designing incremental migration paths, and replacing tightly-coupled systems without taking the business offline.
Migrating monoliths, rescuing codebases, and retiring technical debt.
- Modernised without going offline
- Technical debt paid down on a plan
- A codebase new hires can work in
The problem
The system everything depends on is the one nobody dares touch.
Legacy systems are often the ones that earn the money: an old application that runs billing, a database everything reads from, a program only one person understands. Rewriting such a system in one go is the classic way to lose a year and end up with two systems.
We start by understanding what the system really does, including the things nobody wrote down. Then we replace it in slices: new code takes over one function at a time while the old system keeps running, until nothing depends on the old parts.
What you receive
What a project produces.
A system audit
A written account of the code, the data, the infrastructure and the risks, including what nobody knows.
Documentation of behaviour
What the system does, recovered from the code, the data and the people who use it, before anything is changed.
A migration plan
The order of changes, what each step delivers, and how each can be reversed.
A safety net of tests
Tests that capture the current behaviour, so we know when a change alters it.
Incremental replacement
New components that take over functions one by one, running alongside the old ones.
Data migration
Moving and verifying the data, with checks that old and new figures match.
How we approach it
The positions we take.
Understand before changing
The first deliverable is a description of what the system does. Changes come after.
Replace in slices
Each slice goes live on its own and can be rolled back. The business never depends on a single big switch-over.
Keep the business running
Migrations are scheduled around your busy periods and tested against real data.
How it runs
Four steps, from the first call to hand-over.
1
Audit and characterise
We read the code, inspect the data and interview the people who use the system, then write down what it does. Pricing follows the audit.
2
Safety net and plan
Tests capture the current behaviour, and we agree the order in which functions will be replaced.
3
Replace slice by slice
Each function moves to new code, goes live on its own, and is verified against the old system before the next begins.
4
Retire the old system
When nothing depends on the old parts, we switch them off, archive the data, and hand over documentation.
Is it a fit
When we are the right people, and when we are not.
A good fit
- A critical system is hard to change and few people understand it.
- You inherited code from a team or vendor that has gone.
- Your platform is holding back new features or runs on unsupported technology.
Another route is better when
- The system is small enough to rewrite in a few weeks. A clean rebuild may be quicker.
- You want a fixed price for a migration before anyone has looked at the code. We price after the audit.
- You want an old system kept running indefinitely with no plan to change it. That is a support agreement.
What we ask on the first call
- What does the system do that the business cannot lose?
- Who understands it today?
- What is it written in, and is the source complete?
- What data does it hold, and how clean is it?
- What is driving the change now?
Questions
About Legacy System Modernisation.
Something missing? Write to [email protected] and an engineer will answer.
Rewrite, or migrate step by step?
In most cases step by step. A full rewrite delays value, and often repeats old mistakes because the old behaviour was never written down.
What if we have no documentation?
That is normal. We recover the behaviour from the code, the data and the people who use the system, and write it down.
Can you work with old languages and databases?
We assess this in the audit. If we are not the right people for a technology, we will tell you.
Will the system go offline?
The approach is designed to avoid it. Old and new run together and switch over one piece at a time, with a rollback for each.
Describe what you need.
Describe the problem in plain language. An engineer reads every inquiry and replies within one business day, with a written scope and fixed price before you commit to anything.
- Reply
- Within one business day
- First call
- Free, no commitment
- Confidentiality
- NDA on request, before you share anything
- [email protected]