Keep what the old system knows. Replace the constraints.
Recover the rules and history first. Replace the constraints one working slice at a time.
- 01Assess
- 02Isolate
- 03Build
- 04Migrate
- 05Retire
The old system stays on until the new one produces the same answers from the same records. Retirement is a result, not a date.
The technology aged; the meaning inside it did not
The application was built for an earlier operating model and can no longer be changed at a sensible price: the vendor has moved on, the stack is unsupported, and a field change is quoted like a project. The logic inside it, though, is still right. Thresholds, exceptions, and edge cases were added one at a time over years, largely by people who have since left. Rebuilding from a description of how the business should work discards all of that, and the operation rediscovers each missing rule one incident at a time.
How the problem shows up day to day.
- 01
Nobody can change it safely
Small requests carry disproportionate risk, because the architecture is undocumented and no one can say in advance what a change will touch.
- 02
The system is understood by a few people
How the data really flows, what a field has come to mean, and which quirks are load-bearing sit with a handful of staff, and leave when they do.
- 03
Half the process now runs outside it
Teams keep the real work in exports, spreadsheets, and side databases. Replace only the application and you replace only part of what the business is actually using.
How work moves today.
- 01
Work enters screens built for an earlier process
Users navigate slow forms whose fields no longer match what the job needs, and put the difference in a notes box or leave it out.
- 02
Anything modern needs an export
Reporting, coordination, and integration run on nightly dumps into spreadsheets, so every downstream answer describes last night rather than now.
- 03
Small changes are quoted as projects
A vendor or a single maintainer prices an operational adjustment like a project, so the process bends around the software instead of the other way round.
- 04
Shadow systems fill what is missing
Departments build their own tools at the edges, and the operation ends up spread across the legacy application and the workarounds, with no map showing both.
How the same work moves once the system holds it.
- 01
The rules are read out of the running system
Behaviour, data ownership, integrations, and the workarounds around them are recovered from the system as it runs and confirmed with the people who operate it, before any target is designed.
- 02
One slice at a time, chosen by cost
The workflow carrying the most risk or delay moves first, inside a defined boundary. Everything else keeps running where it is until it earns replacement.
- 03
Both systems run and are reconciled
Shared identifiers link old and new records, and the two are compared on the same work until their outputs agree. A discrepancy blocks the cutover rather than becoming a note.
- 04
Legacy paths retire one by one
Each path is switched off deliberately by a named owner once its replacement has carried real volume, with a rollback available, and the new system is documented and tested so the key-person dependency does not rebuild itself.
What has to be built for that to hold.
- 01
The recovered rule set
States, thresholds, exceptions, ownership, and reporting definitions written down as the system behaves today rather than as a manual once described it, then checked against real records before anything is built.
- 02
Migration and reconciliation layer
Records moved with their history, identifiers mapped in both directions, conflicts held for a person instead of overwritten, and old and new outputs compared until they match. For one retail group, the move to a single PostgreSQL source of truth eliminated 100% of the spreadsheet formula errors.
- 03
The replacement and its interfaces
A maintainable application for the migrated workflows, with APIs so adjacent systems participate through supported interfaces instead of exports and screen scraping.
Screens from a related demonstration.
Captured from Pixelity's fictional product demonstrations. Organizations, people, and records shown are synthetic.
Operations Command Center
A fictional operation on the far side of the move, where activity, exceptions, and reporting read from live records instead of an overnight export.
Open the demonstration- 01Assess
- 02Prototype
- 03Migrate
- 04Operate
- 05Evolve
The kinds of system this usually becomes.
Adjacent problems that often appear together.
Articles that help frame the decision.
Tell us the process everyone works around.
Describe it in a sentence or two. We will come back with what we would build first, what it would take, and whether you actually need us for it.