Legacy system modernisation without stopping the business that depends on it.
We modernise the parts that are actually holding you back, in an order that keeps the system working throughout.
Building and maintaining software since 2007Contributor to Apache OFBiz, an enterprise open-source platform
- InterfaceUntouched
- OldBusiness rulesNew, on trialBusiness rules
- Integration layerAdded first
- RecordsStays where it is
The marks are the cutover window. The line does not stop at them.
The system is not the problem. What it prevents is.
Modernisation is not always the answer. A stable system nobody needs to change is not a problem, and if the constraint is really releases, DevOps is the sharper project.
- Blocksa small feature
Every change takes a negotiation
A small feature needs three people who understand the old parts, and one of them is always busy.
Blocksa small featureEvery change takes a negotiation
A small feature needs three people who understand the old parts, and one of them is always busy.
- Blocksa new system
It cannot connect to anything new
The data exists but nothing else can reach it, so integrations get built as exports and manual steps.
Blocksa new systemIt cannot connect to anything new
The data exists but nothing else can reach it, so integrations get built as exports and manual steps.
- Blocksthe next handover
The knowledge is leaving
The people who know why it works this way are retiring or moving on, and the documentation was never the point.
Blocksthe next handoverThe knowledge is leaving
The people who know why it works this way are retiring or moving on, and the documentation was never the point.
What we take on.
Six capabilities, in the order a modernisation actually runs them.
Assessment and mapping
What the system does, what depends on it, which parts change often and which have not been touched in years.
API and integration layer
Opening the data and functions to newer systems without rewriting what already works.
Incremental replacement
Carving out one capability at a time, running old and new together until the new one is proven.
Data migration and reconciliation
Moving records with a way to prove nothing was lost or silently changed.
Platform and framework upgrades
Bringing supported versions back into range, which is often the cheapest risk reduction available.
Documentation and handover
Writing down what the departing experts know, before they leave rather than after.
Where this page stops: moving a system to a new environment is cloud migration, and building from scratch is custom software. This page owns changing what exists, in use.
See cloud migrationWhich parts to modernise first, judged on two axes rather than age.
Age is the worst reason to modernise something, and the most common one given. The useful question is how often a part changes and what it costs when it fails.
- High cost when it failsChanges often
Modernise first
This is where effort returns the most.
- High cost when it failsChanges rarely
Reduce risk without rewriting
Upgrade versions, add monitoring, document it.
- Low cost when it failsChanges often
Open it up with an integration layer
So it stops blocking other work.
- Low cost when it failsChanges rarely
Leave it
Rewriting this is a cost with no return, and it is usually the largest part of the estate.
We build this grid before proposing work. The bottom-right box is normally the biggest, and naming it is what makes the plan affordable.
How modernisation runs without an outage.
Nothing is replaced until the replacement has been proven against real use, and the plan names what will be left alone.
Map it from the running system
Behaviour, dependencies and change history taken from what is actually deployed, not from documentation written years ago.
Place each part on the grid
Change frequency against failure cost, so the plan names what will be left alone as clearly as what will change.
Open it before replacing it
An integration layer first. That alone often removes the blockage that prompted the call, at a fraction of the cost of a rewrite.
Replace one capability at a time
Old and new running together, with the old path available until the new one is proven against real use.
The only switch-overReconcile the data
Evidence that records match, rather than an assurance that the migration script worked.
Write down what was in people's heads
Captured during the work while the knowledge is still available to ask about.
Where this stops. Moving a system to a new environment belongs to cloud migration. This page owns changing what exists while it stays in use.
See cloud migrationExperience with older systems, without a rewrite-by-default view.
We have no published modernisation case study with a measured before and after. What we do have is a documented history with Apache OFBiz, including a contribution to the project.
- Building and maintaining software since
- 2007Building and maintaining software since
- Projects delivered
- 0+Projects delivered
- Longest-running client integration, still in production
- 9 yrsLongest-running client integration, still in production
- Countries served
- 6Countries served
The nine-year integration is the relevant evidence: keeping something running is the same discipline as changing it safely.
See all case studiesWhere modernisation usually starts.
Situations rather than industries. Legacy constraints look similar across sectors, and we hold no sector-specific evidence to claim.
An unsupported version
Where the platform or framework is out of support and security review has made it urgent.
An integration that will not happen
Where a new system cannot be adopted because the old one has no way to talk to it.
A retirement on the calendar
Where the person who understands it has a leaving date and nothing is written down.
A stalled rewrite
Where a full replacement was started, ran long, and both systems are now in production.
Why we argue against full rewrites.
Replacement is sometimes right, usually when the system does something standard badly and a product exists. We say so when it is.
None of this makes a rewrite wrong in every case. It makes it a decision that has to be argued for, system by system, rather than the default.
What you have when the work ends.
The most durable artefact is usually the integration layer, because it keeps working whatever happens next.
The grid, filled in for your system
Every part placed by change frequency and failure cost, with the reasoning recorded.
An integration layer you own
Often the most durable artefact, because it keeps working whatever happens next.
Documentation written during the work
Captured while the people who knew were still available to ask.
Reconciliation evidence
Proof that the data matched, for each capability that moved.
A written list of what was left alone
With the reason, so the next team does not rediscover the same conclusion.
Supported versions you can patch
The platform and framework upgrades the work needed, so security fixes apply again without a project.
Who we need from your side.
An imminent retirement or handover changes the order of the work. Worth saying early.
The knowledge that is leaving is the most perishable input.
Whoever knows why it works that way
Even partially. Their time is the most valuable input and the most perishable.
Someone who can decide what to leave
The grid produces a list of things not to touch, and that needs authority behind it.
Access to the running system and its history
Version control, tickets and a readable environment. Mapping without these is guesswork.
Whoever owns the business process
Because undocumented behaviour is often a business rule nobody wrote down.
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.
Start with the change that keeps getting postponed.
Describe what your team cannot do because of the older system. We will tell you whether the answer is an integration layer, a replacement, or leaving it alone.