Legacy modernization

Improving a system that cannot be switched off

The system everyone complains about is usually also the system that works. It encodes twenty years of decisions, most of them undocumented and some of them load-bearing, and the reason nobody can explain what it does is that the people who could have retired. The instinct is to rewrite. Big-bang rewrites fail at a rate that is well documented and widely ignored, largely because the new system has to reach feature parity with a specification nobody has ever written down.

What the work involves

  • An audit first, ending in a written recommendation — sometimes that recommendation is to keep it
  • Characterisation tests that capture what the system does now, before anything changes
  • Incremental replacement behind a facade, so value arrives continuously rather than on a promised date
  • Observability added early, because you cannot modernise what you cannot measure
  • Dependency and platform upgrades sequenced so each step is independently shippable
  • Knowledge capture, so the new system is not equally mysterious in ten years

Why we are credible at this

We maintain a platform that has itself been migrated between database engines and framework versions while serving customers, and we know the specific misery of a library upgrade that is fine in the build and different in production.

What moves the price

We quote after discovery and the number is fixed before anything starts. These are the things that move it, so you can see roughly where your project sits before you talk to us.

  • Whether any tests exist today — their absence is the single largest multiplier on this work
  • How much institutional knowledge survives among people still at the company
  • Whether the system can be changed incrementally or is one indivisible artefact
  • Compliance obligations that constrain how and when changes may be deployed

Proof we have done this

Knowing something is wrong before a customer tells usMetrics, logs and distributed traces, self-hosted and actually usedA distributed data layer, chosen deliberatelyDistributed SQL, wide-column, cache, object storage and vectors — each for a reasonThe cluster we run our own company onA production Kubernetes platform, operated by the people who deploy to it

Questions we get asked

Other App Development work

Custom web applicationsThe system your business actually runs on, built properlyAPI and integration developmentMaking two systems agree, including the one with no documentationMobile applicationsCross-platform where it makes sense, native where it does notAI and retrieval systemsAssistants that read your documents, and know what they are not allowed to read
All App Development

Tell us what you are trying to do

A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.

Start a conversationI already use KamoCRMHow we quote