Modernisation

The old system keeps taking orders while you replace it.

Assess, stabilise, migrate and rebuild — in slices, with the old system still serving traffic. Historical records come across with reconciliation reports a finance team can check line by line. This is what that method actually consists of, what each part costs, and which systems are better left exactly as they are.

Talk through your system The whole stack

LayerData & ingestion · Systems of recordthe whole stack

The premise

The rewrite is the version that does not finish.

Every proposal to replace an old system arrives in the same shape, and the shape is the problem rather than the technology underneath it.

The proposal reads well. A second team builds the replacement alongside the current system. At some point in the future the two swap over, everybody moves on a Monday morning, and the old code is deleted. It reads well because it is simple, and it is simple because it has quietly assumed something that is not true: that the business will hold still while the work happens. It will not. Over the eighteen months a serious rewrite takes, tax rules change, a competitor forces a pricing change, a new warehouse opens, a regulator asks for a field nobody has ever captured, and two people who understood the original system leave. Each of those lands on the old system, because that is the one running the company. The new system now has to catch up with a target that is moving away from it, using the smaller of the two teams.

The usual defence is a feature freeze on the old system — nothing changes there until the new one lands. A freeze is a coherent engineering idea and it is not available to a business that has to keep trading. Telling a sales director that pricing cannot change for a year, or a finance team that a statutory reporting change will have to wait for a project, is not a technical decision. It is a decision to stop competing, and it never survives contact with the first quarter that goes badly. What happens instead is that the freeze is agreed, then breached, then breached again, and the rewrite is now chasing a system that is being changed by people who were told they could not change it.

The second thing the rewrite assumes is that anyone knows what the old system does. Nobody does, in full. A system that has been in production for fifteen years does not contain features; it contains accumulated decisions, most of them undocumented and some of them load-bearing. The odd rounding rule in the invoice total is not a bug — it is a settlement agreed with a customer in 2011 that has been quietly correct ever since. A rewrite built from a requirements document written by the people available today reproduces the system they can describe, not the system that is running, and the difference between those two shows up as a month of unexplained variances after go-live.

The alternative is not more planning. It is a different unit of work. Rather than replacing the system, you replace one capability at a time, behind a routing layer, while the old system carries on serving everything you have not got to yet. Each slice goes live on its own, is proved against the old system's own output before anyone relies on it, and can be routed back to the old path in minutes if it misbehaves. The programme is then a sequence of small reversible events rather than one large irreversible one, and it can survive the business changing underneath it — because at every point in the sequence, both systems work.

A replacement is not finished when the new system works. It is finished when the old one is switched off — and that is a different, much later date than the one in the plan.

The mechanisms

Five things make a live replacement possible. Remove any one and it becomes a rewrite.

None of these is exotic. Together they are the difference between a migration you can stop halfway through and a migration you cannot.

01
Strangler-fig routing
A routing layer in front of both systems; traffic moved path by path, old system still authoritative for everything else
The name comes from the strangler fig, which grows around a host tree, takes over its structure gradually, and only at the end leaves nothing of the original. In practice it means putting a routing layer in front of the old system — a proxy, a gateway, or a facade the callers already talk to — so that requests can be sent to either implementation without the caller knowing which answered. On day one it routes everything to the old system and changes nothing. Then one path at a time moves across. The old system is not modified to allow this; it is simply no longer the first thing the request reaches. What this buys you is the ability to move a single capability without coordinating a single other thing, and the ability to move it back.
Every change becomes a big-bang change, because there is no way to have half of the traffic on the new system. The date of the switchover becomes the date the whole programme succeeds or fails on, and no amount of testing beforehand makes that a comfortable date to stand behind.
02
Slicing by capability, not by table
Vertical slices bounded by a business capability, each with its own data, rules and interface, rather than horizontal cuts through the storage layer
The tempting first move is to replace the database, or the front end, or the reporting layer — a horizontal cut across the whole system. It is tempting because it looks tidy on a diagram. It is a trap, because a horizontal slice delivers nothing to the business until every other layer has caught up with it, so it cannot be tested by use and cannot be stopped halfway. A capability slice is vertical: goods-in receipting, or credit notes, or shift rostering, taken from the screen a person touches all the way down to the rows it writes. It is a smaller and messier piece of work, and it is the only kind that can be switched on by itself. The right unit is a thing a person in the business would name if you asked them what they do.
Nine months in you have a new data layer, a new API and no user who has done a day's work on the new system. Nothing has been proved by real traffic, and the first slice to go live goes live carrying every unexamined assumption made since the start.
03
Dual-run and parity checking
Both implementations process the same live input; the new one writes nothing; outputs are diffed field by field and the differences triaged
Dual-running means the new slice receives a copy of the real traffic the old system is handling, computes its answer, and is not allowed to act on it. The old system remains the one that writes the record, sends the email, releases the stock. Parity is the comparison of the two outputs — literally, whether the new answer matches the old one, field by field, across days of real volume rather than a test suite somebody wrote. Every mismatch is then triaged into one of three piles: the new system is wrong, the old system is wrong, or the two are both defensible and the business has to decide which it wants. That third pile is the valuable one, and it is where the undocumented decisions of fifteen years finally get written down. Dual-running is also how you discover the rounding rule from 2011 without anyone having to remember it.
You go live on a slice that passed its tests and find out from a customer that it disagrees with the old system in a way nobody anticipated. Confidence in the programme is spent in a single afternoon, and the next slice will be asked to justify itself for a quarter before anyone will let it near production.
04
Historical data migration with reconciliation
Backfill in dated batches, control totals per period, and a per-record reconciliation report the finance team signs rather than the engineers
Reconciliation means proving, in a document somebody outside the project can read, that what arrived equals what left. Not that the migration script ran without an error — that the ledger balance for March in the new system is the same number as the ledger balance for March in the old one, that the record counts agree period by period, and that every record which did not come across is on a named exceptions list with a reason against it. The output is a report a finance team can check line by line and put their name to, because they are the people who will be asked to explain a variance later, not the people who wrote the migration. Expect the exceptions list to be long at first and expect it to be interesting: it is usually where the genuinely broken historical data has been hiding, and it costs real weeks to work through.
The data is in the new system and nobody can attest that it is complete. That is a problem at year-end, when an auditor asks how you know, and it is a problem long before then, because the first person who finds a missing record will stop trusting every number on the screen — reasonably.
05
The cutover, and the rollback that must exist
A dated change of the routing rule for one slice, with a tested reverse path and a named person holding the decision to use it
Cutover is the moment a slice stops being a shadow and becomes the system of record: the routing rule changes, the new implementation writes for real, and the old path stops being called for that capability. Done this way it is a small event — one capability, one rule, one afternoon — and it happens many times over a programme rather than once. The part that is not optional is the rollback: a tested path back to the old implementation, exercised at least once before it is needed, with a clear statement of what happens to records created in the window between cutting over and rolling back. A rollback that has never been run is not a rollback, it is a hope. Name the person who is allowed to call it, and agree in advance what they are watching that would make them call it.
The switch happens, something is wrong, and the discussion becomes whether to spend the night fixing forward under pressure because going back was never built. That is how a controlled migration turns into an outage, and it is the failure mode that ends up in the trade press.

The sequence

What actually happens, in the order it happens.

Each stage ends with something you can hold, show to a colleague, and argue with. If a stage cannot name its artefact, it has not finished.

01
Assess
A dependency and traffic map of the live system, a list of capabilities ranked by risk and by how self-contained they are, and a written register of the undocumented rules found — each one attributed to the person or the record that revealed it.
Read the system as it runs rather than as it is described. That means the traffic — which endpoints and screens are actually used and by whom, and which have not been called in two years. It means the data — real row counts, real cardinality, the fields that were repurposed for something other than their name. It means the integrations, including the ones that turn out to be a scheduled export nobody owns. And it means the people: the two or three who know why a thing is the way it is, interviewed before they retire or resign. Most of what matters at this stage is discovered by measurement, because the documentation, where it exists, describes an earlier system.
02
Stabilise
A routing layer in production passing one hundred per cent of traffic to the old system, request-level logging on the paths in scope, and a restore of the production data proved in a non-production environment on a known date.
Before anything is replaced, make the current system observable and safe to work near. Add logging where there is none, so that the traffic can be seen rather than guessed at. Get a restorable backup and actually restore it once, into a scratch environment, because an untested backup is a belief. Put the routing layer in front of the system while it still routes everything to the old path, so that the mechanism is proved when it is carrying no risk. Fix the operational bleeding — the nightly job that fails twice a week and is restarted by hand. None of this is modernisation and all of it is load-bearing, and it is the stage most often skipped by programmes that later go badly.
03
Slice one
One working capability behind the routing layer, deployable and reversible, plus a revised estimate for every remaining slice based on what this one really took rather than what was assumed.
Pick the first capability and build it end to end. The right first slice is not the most valuable one; it is the one that is self-contained enough to prove the method and real enough that people will notice it working. Something with a clear boundary, a modest blast radius and an output that can be compared against the old system objectively. Build the whole vertical — interface, rules, storage, the integration points it needs — and resist the pull to generalise it into a platform. The first slice is also where you find out what the routing layer, the reconciliation approach and the parity harness actually cost, which is the number the rest of the plan depends on.
04
Dual-run
A parity report over a full business cycle with every difference categorised and resolved, and a written record of the historical rules the dual-run uncovered — which is usually the most valuable document the programme produces.
Give the new slice a copy of the live traffic and let it compute alongside the old system without writing anything. Run it for long enough to cover the shapes the business actually produces: a month-end, a quarter-end, a payroll run, the seasonal peak — whichever cycles apply. Diff the outputs field by field and triage every difference. Some will be defects in the new code and are fixed. Some will be defects in the old system that have been quietly wrong for years, which is a business conversation rather than a technical one. The remainder are legitimate historical decisions that now have to be made explicit and either kept or deliberately dropped. Parity is not chased to one hundred per cent by force; it is chased until every remaining difference is understood and signed off.
05
Cut over
One capability live on the new system with the old path retired but recoverable, and a signed reconciliation pack for the migrated history — record counts and control totals per period, with every exception named and explained.
Change the routing rule for that one capability and let the new implementation become the system of record. Migrate the historical records that belong to the slice, in dated batches, with control totals per period and a reconciliation report someone in finance or operations signs rather than someone on the project. Watch the agreed signals for the agreed period with the rollback path armed and a named person holding the decision. Then leave the old code path in place, unused but callable, until the next cycle has closed cleanly. Deleting the old path is a separate, later, deliberate act — and then the sequence returns to the next slice, with the routing layer already in place and the method already proved.

The honest test

Some systems are worth rebuilding. Rather more should be left alone.

Age is not a reason. An old system that does its job, is cheap to run and is not blocking anything is not technical debt — it is a paid-off asset, and replacing it converts working software into project risk for no return.

Worth rebuilding

The system is blocking a change the business has actually decided to make — a new market, a new product line, a regulatory obligation with a date on it — and the block has been traced to something specific rather than asserted in general
Change is slow in a way you can measure: a field addition takes weeks, releases require a scheduled outage, and every change carries a real chance of breaking something unrelated
It cannot be operated safely any more — no one can restore it from backup, it runs on hardware or an operating system that no longer receives security fixes, or the licence for a dependency has ended
The knowledge has gone below a floor: nobody currently employed can explain how a core calculation works, and the last person who could has left
Its data is trapped and other systems need it — the integration cost of working around it now exceeds, year on year, the cost of replacing it
The running cost is genuinely disproportionate, not merely visible: a per-seat or per-transaction licence that scales with growth in a way the business cannot get out from under

Leave it alone

It works, it is cheap, and the only complaint is the language it is written in or the decade it was written in — neither of which a customer has ever noticed
It is stable precisely because it is finished: a settled domain, no pending change, and years of production have already found the bugs a rewrite would reintroduce
Nobody can say what would be different afterwards. If the answer to what changes for the business is a better architecture, the honest answer is that this is not yet a project
The real problem is one integration or one report, in which case put an interface in front of the system and leave the system where it is — that is days of work rather than quarters
It is due to be retired for an unrelated reason within a couple of years, and rebuilding it means paying twice for the same capability
There is no appetite for the dual-run and the reconciliation, only for the new build. A modernisation without the proving work is a rewrite with better vocabulary, and it will fail the same way

Asked often

The questions that come up once this is a real decision.

How long does this take?: Longer than a rewrite is quoted at and shorter than a rewrite actually takes, and the useful unit is the slice rather than the programme. Assess and stabilise are typically a few weeks, because they are bounded by how quickly you can observe a live system and get a restore proved. The first slice is the slowest, since it pays for the routing layer, the parity harness and the reconciliation approach as well as the capability itself; slices after it are usually a fraction of that. What decides the total is the number of capabilities and how tangled the data is between them, which is exactly what the assessment is for. Anyone who gives you a programme date before the first slice has been built is quoting a hope.
Can we do this while the team keeps shipping features?: Yes, and that is the point of the approach rather than an accident of it — there is no freeze, so ordinary work continues on the old system. There are two honest costs. The first is duplication: while a capability is being replaced, an urgent change to that specific capability has to be made in both implementations, or the slice has to be finished first. Keeping the slices small is how you keep that window short. The second is attention. The people who know why the old system behaves as it does are also the people the business calls when something breaks, and their time is the scarce resource in the whole programme. Plan for that explicitly rather than hoping it fits around the edges.
What happens to the data nobody understands?: It is catalogued rather than migrated on faith. During assessment, every field is put into one of three buckets: understood and in use, understood and dead, or unexplained. The unexplained bucket is worked through with evidence — what writes it, what reads it, and how the values are distributed — and a field that nothing has written for four years and nothing reads is a strong candidate for archive rather than migration. Where a field cannot be explained but cannot be shown to be dead, the answer is to carry it across unchanged rather than to interpret it, and to record that decision. The dual-run then does the rest of the work: if a mystery field matters, a parity difference will find it. What you must not do is quietly drop it, because the person who needs it will appear at year-end.
What if the original developers are gone?: That is the common case and it changes the method rather than preventing it. When there is no one to ask, the running system becomes the specification: traffic logs say what is used, the data says what is written, and the dual-run says whether your reproduction agrees with the original. This is slower than having someone to ask, and it is more reliable than a memory, because the system cannot misremember. Where source code exists but is unreadable, it is read for the rules rather than the structure — you are looking for the twelve decisions that matter, not a line-by-line translation. It also raises the value of the parity stage considerably, since it is the only place the undocumented behaviour will surface before a customer finds it.
Do we have to move to the cloud?: No. Where the system runs is a separate decision from whether it is replaced, and joining the two is a reliable way to make one hard project into two. There are good reasons to move — hardware you can no longer buy, a data centre contract ending, elastic demand you are currently sizing for the peak — and there are systems with steady load and a paid-for machine where a move adds a monthly bill and no capability. If a move is warranted, it is usually cleaner to do it as its own slice, with its own rollback, rather than bundled into a capability rebuild, so that if something goes wrong you know which of the two changes caused it.

In practice

Make it reversible, and the date stops being the risk.

Every part of this method exists to keep one property: at no point is the business relying on a change that cannot be undone. The routing layer makes a capability switchable. The slice makes the unit small enough to switch. The dual-run means you have seen the new answer against the old one on real traffic before it counts. The reconciliation means somebody outside the project can attest that the history is complete. The rollback means the cutover is an afternoon rather than a night. Take any one of those away and you have a rewrite wearing different words.

It is also worth saying plainly that the right answer is sometimes to do none of it. If the system works, the cost is modest and nothing is blocked, the disciplined move is to put an interface in front of it and spend the money somewhere it changes the business. If you want a second opinion on which of those two situations you are in, we would rather tell you your system is fine than sell you a programme.

Start a conversation How we run an engagement

The last mile into your systems

What has to be true for a system to write into your ERP, HRMS or CRM — and why this is the layer that decides whether any of it was worth building.

Read

From prototype to production

You have a demo that works. What is actually between that and a system your business can depend on?

Read

When not to use AI

Which problems we would tell you to solve with something other than a model, and how to recognise them before you have spent anything.

Read

Loading…

FAQs

Frequently Asked Questions

Industrial AI, robotics conversion and adoption, Industry 4.0 automation and test automation, and the software those systems run inside: enterprise systems (ERP, HRMS, CRM, inventory and production management), web applications, AI agents and automation, and native mobile apps for iOS and Android.

A focused first release typically ships in 8–12 weeks. Multi-module enterprise platforms run 4–9 months, delivered module by module so you are using working software long before the final release rather than waiting on a single big-bang launch.

Both. A well-defined scope gets a fixed price against a signed specification. Longer or evolving builds run as a dedicated team on a monthly retainer. Either way you get a written estimate with every assumption listed before a contract exists, so you can see exactly what moves the number.

Discovery and scoping, then UI/UX design, then two-week build sprints that each end in a working demo. You get a staging environment from the first week, and QA, security review and deployment run inside the sprint instead of being bolted on at the end.

You do, in full, on final payment. Source code, design files, infrastructure and documentation are handed over in your own repositories and cloud accounts. We keep no licence over your product and there is no lock-in to our hosting.

Yes. We connect to MES and the equipment already on the line, accounting, HR and CRM platforms, payment gateways, WhatsApp Business, and legacy in-house databases. Where no API exists we build a sync layer and migrate historical records with reconciliation reports your finance team can check line by line.

Every project closes with a handover: documentation, team training, and a warranty period covering defects at no cost. After that you can run support in-house or keep us on a monthly plan covering monitoring, security patches, and an agreed block of enhancement hours.

We sign your NDA before the first technical conversation. Builds ship with role-based access, encryption in transit and at rest, and audit logging as standard. Production data stays inside your infrastructure and access is limited to the engineers assigned to your project.

Start a project

Didn’t find what you were looking for?

Tell us what you are building. You get scope, a timeline and a realistic cost — not a brochure.

Tools

The stack we build on

We design, build, and evaluate with a modern AI stack—LLMs, vector search, orchestration, and observability—so your features are fast, reliable, and secure.