Extraction comes first
Before anything is designed, we prove the data can be reliably and repeatedly extracted. A replacement plan built before that is a plan built on hope.
Services
It runs on a server in a cupboard. The vendor stopped supporting it in 2018. Two people know how it works and one of them retires next year. Everybody agrees it has to be replaced and nobody wants to be the person who breaks it.
Tell us what the system is and what it holds. We will tell you what extraction looks like.
The situation
The technical work is ordinary. The risk management is not.
Before anything is designed, we prove the data can be reliably and repeatedly extracted. A replacement plan built before that is a plan built on hope.
Legacy systems encode rules nobody wrote down — a rounding convention, an exception for one customer, a status that means something different on Fridays. Finding those is most of the work.
The new system runs beside the old one and reconciles daily. Divergence is investigated as it appears rather than discovered at cutover.
Both run until the new one has agreed with the old one for two full cycles. The retirement date follows the evidence rather than the plan.
The old system’s data is retained in an accessible, documented form after it is switched off, because somebody will ask about a 2019 transaction eventually.
The person who knows the system is the most valuable participant. Replacement projects that route around them fail at the edge cases.
The standard failure sequence is to design the target, build it, then discover in month four that the source data cannot be extracted at the grain the design assumed. Everything after that is renegotiation.
So the first phase is extraction and nothing else: can we get everything out, repeatedly, with a check that proves it is complete. Only then is it sensible to design what receives it. It feels slower and it is the reason these projects land.
A system running fifteen years has accumulated behaviour that exists nowhere in writing. An order type that skips a check. A customer with a bespoke discount hard-coded in 2011. A calculation that rounds differently from the documented method and has been quietly correct for a decade because everything downstream expects it.
These are found by comparing outputs, not by reading documentation. Running the new system against historical inputs and investigating every difference is the only reliable method, and each difference resolves into either a bug in the new system or an undocumented rule in the old one.
Both systems run simultaneously, on the same inputs, with the outputs compared daily. It is more work for a period and it converts a high-risk cutover into an evidence-based decision.
The retirement criterion is that the new system has agreed for two complete cycles — not that a date has arrived. We have extended parallel periods on several engagements and it has never been the wrong call.
Switching a legacy system off usually means losing the ability to query anything that was not migrated. That is a problem three years later when a dispute, an audit, or an acquirer asks about a transaction from before the cutover.
Everything gets extracted into an accessible, documented archive whether or not it is operationally needed. Storage is cheap; reconstructing an unqueryable archive from a decommissioned server is not.
If the person who understands the system is leaving in three months, do the extraction and documentation now and the replacement afterwards. Losing them mid-project is the single worst thing that can happen to one of these engagements.
Where to start
Repeatable, complete, verified against control totals. Nothing else is designed until this works, and occasionally this phase changes the whole plan.
Historical inputs run through the new logic, every difference investigated. This is where the undocumented behaviour surfaces.
Both systems live, outputs compared daily, differences chased. Two full cycles of agreement before anything is retired.
Old system switched off, its data retained in an accessible documented archive rather than left on a server nobody maintains.
Questions
Tell us what the system is and who understands it. Extraction gets proven before anything else is designed.