Old systems, made fast enough and open enough to build on
Much of a company’s value sits in systems that are hard to change. We put documented APIs around them, fix what makes them slow, and plan migrations that happen in steps instead of one risky cutover.
When clients need this
- A core system works, but every change takes months and nobody wants to touch it.
- Automation projects stall because the data is only reachable through a screen or a nightly export.
- Reports or pages that should take seconds take minutes.
- A migration has been planned for years and keeps slipping because the cutover is too risky.
How we build it
We measure before we change anything. Query plans, request traces and batch timings show where the time actually goes.
We wrap the old system in a documented API so new software can use it without touching its internals. Then we move functionality across one piece at a time, with both paths running until the new one is proven.
Performance work is targeted. We fix the slow queries and hot paths the traces point to, and we write tests around current behavior before we refactor it.
Tools we use
- OpenTelemetry tracing to find where requests spend their time
- Change data capture, for example Debezium, to stream changes out of older databases
- An API gateway to route traffic between old and new code during a migration
- The language your team will live with, whether that’s TypeScript, Python, Java or C#
What we don’t do
- We don’t propose a full rewrite when an API and targeted fixes will do.
- We don’t do big-bang cutovers.
- We don’t refactor code we can’t test first.