Move off the system you have outgrown, without stopping the business.
An ERP module that no longer fits, an application one contractor understands, a codebase nobody wants to change. We replace it one working slice at a time, with the old system running until the new one has earned its place. Scope is agreed against a working version you have used, and the source sits in your repository from the first commit.
Try a working versionThe situations that bring people here.
Two voices, usually in the same company. Both are right, and the engagement is shaped so that both can see what is changing.
Running the business
It is held together by one contractor and nobody wants to touch it.
The knowledge is real; it just lives in one person. We start by writing down what the system actually does today, from its behaviour rather than its documentation, and that becomes the first thing you can check.
Running the technology
We are moving off one module of the ERP, and it has to happen without stopping the business.
The module is rebuilt beside the ERP, fed by the same data, and switched over by process rather than by a cutover weekend. The ERP keeps running for everything else.
Running the business
Every change to the old system costs more than the last one, and the vendor's answer is a new licence.
We assess what the licence is actually paying for, and propose the smallest replacement that removes the dependency. Sometimes that is a module; sometimes it is an integration.
Running the technology
I have the team for the roadmap. I do not have the team for the roadmap plus the legacy estate.
We take the estate. Your engineers stay on the roadmap, review our pull requests, and receive a system they can operate at handover.
See the first slice working before we scope the rest.
Modernisation programmes are usually scoped from a document that describes a system nobody has seen yet. We scope from the opposite direction. After one conversation and one real example — an export, a screen, the process as it runs today — you get a small working version of the first slice, in your terminology, with your data where we have it.
You use it. What is right stays; what is wrong is corrected while it is still cheap to correct. Then scope, exclusions, measures of success, milestones, fees and handover are written down against that version, before the project starts.
The working version is included before commitment, and it is yours to keep whether or not the work continues.
What we do in this practice
01
ERP module replacement
Rebuild one module — inventory, dispatch, invoicing, reconciliation — beside the ERP, on the same data, and retire it by process. The rest of the ERP is untouched.
02
Legacy application rebuild
Applications on frameworks that no longer receive updates, rebuilt on a supported stack with the business rules preserved and the behaviour checked against the original.
03
Integration and APIs
Where the real cost is people re-keying between systems. Maintainable integration code in your repository, with the failure cases handled visibly rather than silently.
04
Data migration
Reconciled, rehearsed and repeatable. Migration runs are scripted so that the final one is the fifth time it has worked, not the first.
05
Cloud and hosting moves
From a server under a desk, a single VM or a hosting contract that has become the risk. Environments defined as code, with the cost model written down before the move.
06
Keeping the old system safe meanwhile
Fixes, monitoring and a documented map of the current system while its replacement is built. The estate stops being one person's memory.
Delivered work
Excel-led goods tracking, rebuilt as one shared operational record.
For Muztrans, a UK transport and storage provider, an iPad app, an admin portal and a customer portal that put goods, orders, reports and delivery evidence on the same record. The operations team, the warehouse and the customer see one verified status instead of three.
The working version on our See it work page is drawn from this engagement.
Operate the working version →How a modernisation engagement runs
00
Working version included before commitment
One conversation, one real example, and a small working version of the first slice for you to use. It is yours to keep, and it makes every number below more reliable.
01
Map the current system from its behaviour
What it does, what depends on it, which rules are load-bearing and which are habit. Written down and agreed before anything is replaced.
02
Build beside, switch by process
The new slice runs alongside the old system on the same data. Teams move over when the new version is right for them, not on a cutover date.
03
Delivery in sprints, reviewed by your team
Two-week cycles with a working environment at the end of each. Your engineers review pull requests from the first sprint if you have them; if you do not, we document as if you will.
04
Retire, hand over, hold
The old system is switched off only when the measures of success agreed at scope are met. Source, environments, decisions and handover notes are already in your hands; a stability period follows against thresholds agreed in advance.
Questions we are asked
Do we have to stop using the old system while you build?
No. The new slice runs beside it on the same data. The old system keeps running for everything not yet replaced, and is retired by process once the agreed measures are met.
Who owns the code, and where does it live?
You do, from the first commit. The repository is in your account; we work in it. Access, credentials and infrastructure definitions transfer as part of handover, in a state another capable team could operate.
How do you use AI in delivery, and what does it not touch?
AI is used inside our delivery to analyse exports and logs, draft first-cut screens and tests, and assist review. Everything it produces is reviewed by an engineer before it reaches your repository, and your data does not leave the environments agreed at contract. The detail is on the How we build page.
Can our own engineers work alongside yours?
Yes, and we prefer it. Your team reviews our pull requests, owns the roadmap, and takes over sections as they are ready. The engagement is shaped so that handover is a stage, not an event.
What if the honest answer is that we do not need a rebuild?
Then that is the answer. Sometimes the right move is an integration, a stabilisation retainer or a supported upgrade. We recommend the simplest sufficient option and say so in the first conversation.
Next
Show us the system. We will show you the first slice working.
Show us what needs to work →United Kingdom · European Union · India