We have no documentation for our software
Most of the business systems Solve With Software takes over have no documentation, or documentation that describes a version from years ago. It slows the first week and changes nothing after that. We work out what the system does from the code, the database and the people who use it, and write it down as part of the assessment, so the knowledge stops depending on who's in the building.
Free · 1 hour · no obligation
What no documentation usually means
It rarely means nobody knows anything. It means the knowledge is spread out: some in the code, some in the database, most of it with the three people who've used the system longest, and a bit on a printout by the despatch desk. The developer who could have written it down was busy building it, and then they left. That's the state of most bespoke software in the country.
Where it bites:
- You can't brief another developer, so every quote you get is a guess.
- A supplier proposes a full rewrite because they can't see inside the thing they'd be replacing.
- A new starter takes months to learn the system, and learns the workarounds along with it.
- Nobody changes anything, because nobody knows what else a change would touch.
How we work out what it does
Four sources, cross-checked against each other.
The code. Even without a comment in it, code says what it does. We read it and map the screens to the tables, and the tables to the processes. Where there's no source code at all, the compiled program and the database still tell most of the story.
The database. The schema is the most honest document a system has. Tables, relationships, the columns nobody uses any more, the one that changed meaning in 2014 and never got renamed.
The people. We sit with the people who use the system and watch the work go through it, and we ask about every workaround. The workarounds are where the undocumented rules live.
The paperwork around it. The spreadsheets, the printouts, the email templates, the link to Sage. Anything that goes in or comes out.
Then we write it down: what the system does, what depends on it and what it depends on. That document is section two of the assessment report, and the report is yours.
Do we need to find the original developer?
No. Helpful if you can, not required. An hour with them fills gaps faster, but most takeovers happen without the original developer, because the reason you're reading this is that they're not available. The system, the data and your team carry enough of the story between them.
Can you take it over without the source code?
Usually. It's a constraint, not a dead end. Sometimes the code can be recovered from the installed system or an old backup. Sometimes the right answer is to keep the running system supported while a replacement is built alongside it, sharing the same data, so nothing is lost while the new one takes over one process at a time. The assessment establishes which situation you're in before anyone spends money on either.
What it costs
The legacy system assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. An undocumented system needs more time inside it than a documented one, and the price reflects that, stated up front rather than discovered later. Everything after the assessment is priced by the report: a fixed price for each option.
Your data
Nothing changes during discovery. We read; we don't change. When work follows, it never touches your live data until it has proven itself somewhere else: built and tested against a copy in a test environment, then run in staging alongside the live system with the data migrated, checked and reconciled there first. Only when the tests have shown it's safe does anything connect to live, and the old system stays available as a fallback until you're confident.
The risk of leaving it undocumented
Every month without documentation is a month the business runs on memory. People leave, and memory goes with them. A rewrite quoted without a map of the rules loses the rules, and they get rediscovered in production, one complaint at a time.
The documentation is also what makes a fixed price possible. Nobody can price what they can't see.
How we approach it
Understand first, then stabilise, then modernise one safe step at a time. Marc Allington leads the discovery and the work that follows. He has built business systems in VB, Access, SQL Server and .NET as well as on the web and in the cloud, so the code we're reading is usually code we've written the like of ourselves. Everything we build afterwards runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment, and it comes documented.
How discovery works, step by step
The same method for every undocumented system, whether it's VB6 or Node:
- Inventory. Every screen, report, scheduled job, integration and file the system touches. Output: a system map.
- Data model. Every table and relationship, what each holds, and which screens write to it. Output: a data dictionary.
- Walk-throughs. Each main process followed end to end with the person who does it, workarounds included. Output: process notes.
- Code reading. The screens and processes matched to the code, and anything the code does that nobody mentioned flagged. Output: the hidden rules.
- Environment. Hosting, backups, source control, licences, and the support status of each, with dates. Output: the technical state and the risk register.
Each source is checked against the others. A table with no screen that writes to it, a screen nobody mentioned in a walk-through, a job that runs at 2am: each mismatch is a question, and we keep asking until the map closes. Anything still uncertain is stated as uncertain in the report.
This is sections two, three and four of the assessment report. It's what makes a fixed price possible.
Questions
What people ask before they book.
Will you need a lot of our team's time?
Some, and it's the most valuable part. An hour or two with each person who uses the system most. They know the workarounds; we know how to turn them into a specification.
What if the code has no comments?
Most doesn't. Code without comments still says what it does; it just doesn't say why. The why comes from the people and the data, which is what the walk-throughs are for.
Can you document it and leave it at that?
Yes. The documentation is section two of the assessment report, and the report is yours whether or not any work follows. Take it to us, another developer, or nobody.
Our documentation exists but is out of date. Does that help?
Yes. It tells us what the system was meant to do, which we compare with what it does now. The gap between the two is usually where the interesting rules live.
How do you know you've found everything?
We cross-check the code, the database, the walk-throughs and the paperwork against each other, and every mismatch becomes a question. When the map closes, we stop. Anything we're still not sure of is written in the report as not sure, not glossed over.
Start with a free consultation
An hour on your system, online or by phone. From there we size the assessment, from £395 + VAT, and give you an exact price before you commit.
Want the numbers first? See how pricing works.
Written by Marc Allington, founder. .