Change systems you
cannot switch off.

The systems that most need changing are the ones that cannot be stopped. Payroll runs Thursday, dispatch runs continuously, and the finance close does not move because the software is being replaced.

Nobody wrote the behaviour down, the two people who understood it have left, and every proposal to rewrite it has stalled on the same question: what exactly does it currently do?

What we do

Assessment

Architecture, data model, integrations, and — most importantly — actual usage. Which features are load-bearing, which are dead, and which are being routed around by hand. That last category is usually the largest and it never appears in the documentation.

Recovering undocumented behaviour

We use the same field method we use for user research, pointed at the system: observe it in use, interview the people who maintain the workarounds, and reconstruct the specification from behaviour rather than from intent.

Sequencing

A roadmap ordered by risk and dependency, not by what is most annoying. Usually the strangler pattern — new functionality intercepts and gradually replaces the old system while it keeps running — because a big-bang cutover requires a complete specification of a system nobody has.

Interface work against the live system

Frequently the fastest visible return: the underlying system stays, the daily experience of using it improves, and the structural work continues behind it.

Why rewrites usually fail

A rewrite asks you to fully specify a system nobody fully understands, while the original continues to change. Incremental replacement is less satisfying to propose and considerably more likely to be finished.

If you are weighing the two, an assessment is three to four weeks and will tell you which one your situation actually supports.