- Challenge
- A codebase that has grown for years has no clean seams. Touch one file and ten others break, because nothing records which parts really depend on which. That is what makes teams choose the big-bang rewrite: it feels like the only way to get out. The question we set out to answer was whether a large, tangled system can be moved in pieces instead — with the behaviour of every piece proven before and after it moves.
- Solution
- We mapped the dependencies across the whole 44,000-line application first and used that map to cut it into 14 ordered units, so each one could be moved with everything it depends on already in place. Then we migrated unit by unit under AI agents working to that order, writing characterization tests around each unit before it moved so its behaviour was pinned down rather than assumed. The public API was held stable throughout, which meant existing clients kept working while the migration was in progress. The rewritten data layer replaced hand-written queries with an async ORM, and the largest functions were split into small, separately testable parts.
- Result
- 11 of the 14 units moved — 79% of the system — with 918+ passing tests written along the way, 576+ redundant database calls removed, and no broken API endpoints at any point. The system stayed usable the entire time. We stopped at 79% because the method was proven by then; this was R&D, not a product we shipped.
R&D
Migrating a 44,000-line legacy system, unit by unit.
Most legacy rewrites fail the same way: the team goes dark for a year, the old system keeps drifting, and the new one arrives with different behaviour nobody can prove. We wanted a method where the system stays usable from the first day to the last, so we ran it ourselves before offering it to anyone.
This is R&D we ran — a capability we deliver, not a client production system. Every number on this page comes from that R&D run.
Legacy modernization · R&D project
A method for moving a system that is still in use.
Run as a paid R&D project during the founder's prior engagement, with permission to offer the same capability through Cloverity. Supporting stack: Python with FastAPI, async SQLAlchemy, pytest, and React on the front end; dependency mapping with graph clustering; migration work driven by Claude Code agents under human direction.
Outcomes
What the run actually measured.
These are the numbers from the R&D run itself — measured, not modelled. We publish nothing we did not count.
44,000
lines of legacy code mapped and sequenced into 14 units
11 of 14
units migrated — 79% of the system, at which point we stopped
918+
tests written to pin behaviour before and after each unit moved
576+
redundant database calls removed when the data layer was rebuilt
What we did not measure: elapsed time, cost saved, or lines per day. Those numbers exist for a lot of migration pitches; we did not track them here, so we do not quote them.
Have a system nobody wants to touch?
Tell us about itWhat we deliver
The parts of this that carry into client work.
The R&D was the rehearsal. What we take into a real engagement is the method, not the codebase.
Map before you move
We start by producing a dependency map of the existing system and turning it into an ordered list of units. That order is the whole difference between an incremental migration and a cascade of breakages — and it also tells you, before any code moves, how big the job really is.
Tests first, so behaviour is provable
Each unit gets characterization tests written around its current behaviour before it is touched. After the move, the same tests have to pass. That is what lets a migration be reviewed by someone who was not in the room.
The system stays up
The public interface is held stable while the inside changes, so downstream consumers keep working and the business does not have to schedule a dark period. You can stop between units and still have a working system.
Agents do the volume, people set the direction
AI agents handle the mechanical bulk of the translation under a defined order and a test gate. The sequencing, the architectural calls, and the review stay with engineers — which is what keeps the output reviewable.
Scope, sequence, and effort for your system come out of the mapping step, not out of a template — so the first thing we do on a real engagement is measure your codebase.
Is a rewrite the only option on the table?
Send us the shape of the system — the language, roughly how big it is, and what breaks most often. We will come back with how we would map and sequence it, and an honest read on whether an incremental migration is the right call for you.