Modernise the system without turning it off
You keep the software your business runs on. We move it forward one workflow at a time, so there is never a weekend where everything depends on a cutover going right.
The short version
4 things that decide this
- 01A full rewrite asks you to reproduce twenty years of undocumented behaviour before you get any benefit. That is why so many stall.
- 02Modernising in slices gives you working improvements early, and every slice can be reversed on its own.
- 03Hashlogics built Cruise Search AI as a module inside the client's existing WordPress site, so the site stayed live the whole time.
- 04The first job is not code. It is finding out what the old system actually does, including the parts nobody has documented.
Nobody knows what the old system does
The person who wrote it left. The documentation describes version two, and you are on version nine. The behaviour everyone relies on is in the code, and some of it looks like a bug until you find out a whole department depends on it.
That is what makes a rewrite dangerous. You are not rebuilding a specification. You are reverse-engineering years of decisions, most of which were never written down, while the business keeps running on the thing you are trying to replace.
A rewrite also pays you nothing until it finishes. Halfway through, you have two systems, twice the work, and no benefit.
What we have shipped
Counted, not estimated
22
systems in production
1
AI module retrofitted into a live WordPress site: Cruise Search AI
5
permission tiers TankAware replaced paper logs with
8
systems TomoDomo replaced with one dashboard
How we take a system forward
Each step leaves you with something working. None of them requires a weekend where everything has to go right.
Find out what it really does. We read the code and watch the traffic, because the documentation and the behaviour disagree.
Pick the workflow that hurts most, and check that it can be moved on its own.
Put the new path beside the old one, with the old one still able to serve.
Move a share of the traffic across, watch it, and keep the way back open.
Retire the old path only once the new one has carried real load for a while.
Repeat, until what is left of the old system is small enough to be boring.
- ReadThe code, and what it really does.
- SliceOne workflow that can move alone.
- ParallelNew path beside the old one.
- SwitchTraffic moves. The way back stays.
- RetireOld path off, once proven.
The way back stays open through Switch, which is the step most projects skip. A migration you cannot reverse is a migration you have to get right first time.
Two systems telling you different numbers
The dangerous window is the one where old and new both run. Both hold data. Both are right about something. Your finance team will notice before your engineers do.
We settle that before any traffic moves. One side owns each record and the other reads it. Where both must write, the operation is built so a repeat is harmless, because a network timeout means the same request arrives twice. Cruise Search AI sits inside a live WordPress site and passes validated searches to the client's own cruise engine, which stays the source of truth.
- One system owns each piece of data, and it is written down which one.
- Repeated requests do not create duplicate records.
- A daily reconciliation compares both sides while they overlap.
- The switch back is tested before the switch forward is attempted.
What we modernise onto
Front end
Back end
Run
Systems we have worked beside
“They really help you understand the problem and deliver solutions in a short time frame.”
Johannes Peter · CEO, TomoDomo Coliving
The big rewrite against modernising in slices
Both end with a modern system. Only one of them pays you before it finishes.
| Criterion | The full rewrite | How we work |
|---|---|---|
| When you see a benefit | At the end, if it gets there. | After the first slice, and after every slice. |
| What happens if it stalls | You are running two systems and paying for both. | You stop. What already moved keeps working. |
| Undocumented behaviour | Discovered by users after go-live. | Found by reading traffic before anything is replaced. |
| The cutover | One weekend, with the business holding its breath. | A share of traffic at a time, with the way back open. |
| Who carries the risk | You do, and it arrives all at once. | Spread over slices, each one reversible on its own. |
01Should we rewrite the system or modernise it in place?
Modernise in place unless the old system cannot support the next workflow at all. A rewrite makes you reproduce every undocumented behaviour before you get any benefit, and the business is running on the old thing the whole time. Rewriting is the right call when the platform itself blocks you, and we will say so when that is what we find.
02Can you work on a system whose original developers have gone?
That is the normal case, and it is exactly what the paid two-week diagnostic is for. We read the code and watch what the system actually does in production, because the behaviour and the documentation always disagree by the time a system is old. You get a written map of what is there before anyone proposes changing it.
03Will the system stay available while you work on it?
Yes, that is the point of the approach. New paths run beside the old ones and take traffic gradually, so there is never a moment where everything depends on one cutover. Cruise Search AI went into a live WordPress site that kept serving customers throughout.
04What happens to the data during the move?
One system owns each record at any moment, and which one is written down before anything moves. While both run, a daily reconciliation compares them so a mismatch is found by us rather than by your finance team. Repeated requests are built to be harmless, because timeouts make the same call arrive twice.
05Our system is on an old framework version. Is that the problem?
Rarely on its own. Old versions matter when they stop receiving security fixes or block an integration you need, and then upgrading is unavoidable. Being old is not the same as being wrong, and replacing working code because it is unfashionable spends budget without buying anything.
06Can we add AI to the old system, or does it have to be replaced first?
You can usually add it without replacing anything, because AI reaches the old system through its existing interfaces. Cruise Search AI is an AI module inside a WordPress site, backed by FastAPI and LangGraph, handing validated searches to the client's own engine. The old system stayed exactly as it was.
07How do you decide which part to modernise first?
Take the workflow with the highest pain and the cleanest edges. Pain gives you a benefit people notice; clean edges mean it can move without dragging half the system with it. Where those two point at different workflows, we start with the one that can be reversed most easily.
08What does a modernisation cost?
Cost is driven by how tangled the old system is, how many integrations depend on it, and how much of its behaviour is undocumented. Nobody can quote that responsibly from the outside, which is why the diagnostic is paid and short. You get a fixed price for the first slice, then decide whether to continue.
Related
- Custom software development →When the answer is a new system after all.
- Web app development →Where most modernised workflows end up.
- Build vs buy software →The decision before this one.
- Idempotency key →Why a repeated request must not create a second record.
- Cruise Search AI →AI retrofitted into a live WordPress site.
