What a Codebase Review Finds
A codebase review of an old system will confirm the technology is old. The findings that change the plan are about how people work around it, the data, the connections nobody listed and who knows what.
Firms expect a codebase review to say their technology is old, and it usually is. The findings that change the plan are about people, data and the jobs nobody listed.
Only one of the six layers a review checks is the code, and the findings that most often reorder a roadmap come from the other five.
Any vendor can tell you an old system needs replacing. The useful question is what to replace, in what order and at what price, and nobody can answer that from a sales call. A number quoted from a brief is a number you find out is wrong in month three.
Before we quote a modernization, we read the system. After the free thirty-minute assessment, the first paid step is the review: a codebase review and roadmap at a fixed price agreed in writing, typically two weeks for one system and up to four when there are several. It works down through the system one layer at a time, from what people see to what only one person knows.
The checklist, layer by layer
How people work around it
What we check: we sit with the people who use the system through a normal day and note where they work around it: the spreadsheet open beside the screen, the sticky note with the steps, the report they rebuild by hand.
What changes the plan: the most expensive problem is often a workaround nobody counts as part of the system. It lives outside the code, so rewriting the code would never have fixed it.
The code
What we check: how big it is, how old, what it is written in and on which version, whether that version still gets fixes, how much of it automated tests cover, and where changes have clustered over the years.
What changes the plan: the code is usually better than its reputation, except in two or three places that every change has to pass through. Fixing those first can be worth more than rebuilding the rest.
The data
What we check: where the data lives, how clean it is, and what the system tolerates that it shouldn’t, such as blank fields, duplicate clients and dates stored as text.
What changes the plan: the database often holds business rules the code doesn’t: triggers, stored procedures, a nightly job that quietly repairs yesterday’s records. Those rules have to move too, and nobody listed them.
The connections
What we check: every system it talks to, every file it sends or receives, every scheduled job and every report that leaves the building.
What changes the plan: there is usually one more connection than anyone mentioned, such as a file dropped on a server for a partner or a report emailed to a regulator every quarter. Miss it, and the day the old system is switched off, something outside the firm stops arriving.
Security and hosting
What we check: where it runs, who can get in, where the passwords live, what is patched and what is past its support date.
What changes the plan: the keys are often held by a person or a former vendor rather than by the firm. Getting them back into the firm’s own accounts is often the first piece of work, before anything is rebuilt.
Who knows what
What we check: who understands which part, who is the only one who does, and what happens when they are away.
What changes the plan: how much depends on one person. When the answer is “everything”, the roadmap starts by getting that knowledge written down, as The System Only Dave Understands describes.
A review that only reads the code, or only interviews the managers, misses the layers where the plan-changing findings sit.
What the review does not assume
The review does not assume the answer is a rewrite. Sometimes the right roadmap is to fix the two worst modules, connect the system to the ones around it, and leave the rest alone for years. Sometimes it is to replace the whole thing, a piece at a time. Occasionally it is to change nothing yet. A review that can only ever recommend the work its author sells is a sales call with extra steps.
Nor does it price the whole modernization. It fixes the price of the first phase, and the roadmap for the rest gets more precise with every piece delivered. A full price quoted before the first piece is built would be a guess, and you would pay for it.
What you get at the end
You get a roadmap in plain language that you can forward to someone who was in none of the meetings: the order the pieces move in, why that order, what done looks like for the first piece, and a fixed price for it. You paid for it, so it is yours, and it is written so another team could pick it up if you chose one.
Thirty free minutes first: does your system need a review at all?
Book Free Assessment