Case study / Software Solutions
A reporting system replaced while the line kept running.
A plant reporting application that still worked and could no longer be changed was decomposed and migrated in controlled releases, with the old and new paths running in parallel until interfaces, figures and recovery had each been accepted separately.
- 0
- planned production shutdowns
- 4
- controlled releases, each independently reversible
- 9 weeks
- of parallel running before the old path was retired
Situation
The context
The application produced the figures three plants planned against. It had been extended for fifteen years by people who had since left, its behaviour was understood empirically rather than from documentation, and no change had been attempted in four years because nobody was confident of what a change would do.
It was not failing. It had simply become something nobody was willing to touch.
The first task was not to design a replacement. It was to recover what the existing system actually did — from its behaviour, its configuration and the people who used its output — so that a replacement could be checked against something rather than against an assumption.
Intervention
The intervention
The system was decomposed along its interfaces rather than along its screens, each piece was rebuilt behind the interface it already presented, and the two paths ran side by side until the figures they produced agreed for long enough to retire one of them.
Rule recovery
Behaviour traced and written down before anything moved
Decomposition
Split along interfaces, not along the user interface
Parallel running
Both paths live, figures compared daily
Handover
Run-books and support model as acceptance conditions
Delivery path
Nothing was retired until its replacement had been proved in production.
Each release added a new path without removing the old one. That made every stage reversible, and it made the reconciliation between the two the acceptance test rather than a separate assurance exercise.
Weeks 01–06
Recover
Traced calculation rules, interface contracts and failure behaviour from the running system and from the people who relied on its output.
Decision gateRule set documented and confirmed by plant usersWeeks 07–12
Decompose
Defined the seams — interfaces, data ownership and reporting boundaries — and sequenced the releases so each could stand alone.
Decision gateRelease sequence and rollback path approvedWeeks 13–30
Parallel run
Delivered four releases, each running alongside the existing path, with daily comparison of outputs and divergences investigated before the next release.
Decision gateFigures reconciled for the agreed window per releaseWeeks 31–36
Retire and hand over
Retired the old path once reconciliation held, completed run-books and support arrangements, and closed the parallel infrastructure.
Decision gateOperational acceptance and handover complete
Operating shift
The rewrite was ordinary. The sequencing was the engineering.
What made this deliverable was not the technology chosen but the decision to never be in a position where going back was impossible. These are the practical shifts the case study is designed to make visible.
FromBehaviour known empirically
→ToRules written down
The recovery stage produced an artefact the organisation kept, independently of whether the replacement had ever been built.
FromOne cutover to survive
→ToFour reversible releases
Each release could be withdrawn without affecting the others, so no single event carried the whole risk.
FromTesting against a specification
→ToReconciliation against production
The old system was the test oracle, which is a stronger check than any specification written after the fact.
FromDelivery ending at go-live
→ToHandover as an acceptance condition
Run-books, failure modes and the support model were deliverables rather than courtesies extended afterwards.
Evidence record
A result with its provenance attached.
The published story keeps the result, the supporting artefact and its limit together.
- 0
- planned production shutdowns
- 4
- controlled releases, each independently reversible
- 9 weeks
- of parallel running before the old path was retired
Evidence attached
- Recovered calculation and interface rule set
- Release sequence with per-release rollback path
- Daily output reconciliation record across parallel running
- Operational acceptance and handover pack
Capabilities involved
- Application modernisation
- Enterprise system integration
- Data engineering and reporting
- Quality assurance and testing
- Secure development practice
- Application support and enhancement
- Nature of the work
- No AI involved. The reconciliation was a deterministic comparison of two outputs over the same inputs.
- Baseline
- Production shutdowns planned for the migration at the point of engagement, and the four-year interval since the last successful change to the system.
- Data sources
- The existing application’s outputs and configuration, plant interface logs, and the release and change records held in the client’s service-management platform.
- Human-control point
- Each release was accepted by the client’s plant systems owner against the reconciliation window agreed for it; retirement of the old path required the same approval.
- Technology used
- The replacement application built during the engagement, the client’s existing plant interfaces retained unchanged, and the parallel-run comparison harness.
- Measured result
- The migration completed with no planned production shutdown, across four releases, following nine weeks of reconciled parallel running before retirement.
- Evaluation period
- The thirty-six week delivery, plus eight weeks of post-retirement operation.
How to read these figures
Bring your context
Have an application nobody is willing to change?
Tell us what it does, what would happen if it stopped, and how long it has been since anyone altered it safely. We will start with your environment and be precise about which experience transfers.
- Response
- One working day, Monday to Friday