Platform & Modernisation
The system is taken apart in slices while it keeps serving: the data model repaired, the contracts made explicit, the architecture enforced by the build rather than by whoever reviews the pull request.
What changes
Not the framework version. These are the things that make a system expensive to own, and they are what the work is aimed at.
Who it is for
Not because the team got worse. Because each change has to be safe against a system nobody can hold in their head, and the only way to be safe is to be slow.
Eighteen months, during which the current system has to keep running and keep changing anyway — so you would be paying for two systems and getting the benefit of neither until the end.
The knowledge left with them. What remains is code that works, a deployment nobody wants to touch, and a set of assumptions that were never written down.
What we do
Every line below is something that exists when the work is finished — a service, an index, a check that runs in your pipeline.
What you get
Objects rather than activities. Each of these is something you hold, in your own repository, whether or not we are still working together.
What runs, what calls what, what is used, and what has been dead for three years. Usually the first document about the system that has ever been accurate.
One capability moved to the new path behind routing, with the old one still there until it is proven. The proof that the approach works arrives in weeks rather than at the end.
The boundaries you agreed, enforced by the build. Rules that live in a document decay in the first busy week; rules that fail a merge do not.
Documented as we go, with the reasoning attached. The measure is whether your engineers can make the second change without us, not whether we could make it faster.
Stack
Chosen per system rather than per company. Where two things sit together below, we treat them as interchangeable and pick on the day.
Engagement
Discovery is almost always fixed scope — it has a definite output and you should be free to take the map and stop. The migration itself runs as continuous delivery, because a slice-at-a-time plan that is priced in full up front is a rewrite with extra steps.
A defined deliverable, priced once — after discovery has said what it is, never before. What is in, what is deliberately out, and what we are assuming about your data and your deadlines is written down first.
Suits A first version, a migration with a known end, or a pilot with a decision at the end of it.
A team on your work month to month. A written update every week and a working build you can open — not a status percentage, the thing itself, running.
Suits A product still finding its shape, or a system that needs to keep moving after it launches.
Engineers inside your team: your repository, your conventions, your release process, your stand-up. A good deal of our work is delivered this way, so it is a shape we have real practice at rather than one we are trying on.
Suits A team that knows what to build and is short of the people to build it.
2–3 weeks
The written map: what exists, what is used, what is load-bearing, and where the first slice should be cut.
4–8 weeks
One capability migrated and serving production traffic behind routing, with the old path still available.
alongside
Architecture, types and dependency checks failing the build from the first slice, so the new code cannot drift the way the old code did.
from about 10 weeks
A slice at a time, each one shipped. You can stop at any point and keep everything migrated so far.
Indicative, and stated as ranges on purpose. What moves them is how many surfaces you need at once, how much of the existing system has to keep running, and how quickly decisions can be made on your side — never how many people we add.
Related work
2023 – 2025
Field operations
A web platform, a mobile application and a dedicated notification service, built as one system and kept running through fifteen months of continuous delivery. Three surfaces, one set of contracts, and a release cadence that never stopped to let the others catch up.
2024
Education
Parents wanting to know where a school bus actually is, and schools wanting to answer that without a phone call. Live vehicle positions, route adherence and arrival alerts, on a platform built from the start to be handed over — which it was, into the client’s own repositories.
Questions
Because every slice reaches production on its own and the old path stays until the new one is proven. A rewrite pays off only if it finishes; this pays off at each slice, and stopping halfway leaves you better off rather than stranded between two systems.
It has to. Routing sends one capability at a time to the new path while everything else carries on untouched, which is also what makes each step reversible — if a slice misbehaves, the traffic goes back.
No, but it changes the order. The first tests are written around the behaviour being moved, not around the code being replaced — they describe what the system does today, so there is something to check the new path against.
Then we will say so, in discovery, before you have spent anything on the alternative. It is rare — usually when the system solves a problem the business no longer has — and it is a much easier conversation to have with the map in front of you.
If you want us to. The work is done in a way that does not require it: your repository, your accounts, documented as we go. Staying should be a choice you keep making rather than a dependency you cannot leave.
Start here
Or what is breaking, or what has to go faster. You will get a straight answer from an engineer who would do the work.