Taking Over Software That Has No Documentation

Yes. Software with no documentation can be taken over, because the code and the database are themselves a complete record of what the system does. A new team reads them, runs the application in a safe copy, traces how the main tasks work, and writes down what it finds. Missing documentation makes the start slower. It does not make the system unsupportable.

Signs this is your problem

• The people who built the system are gone.
• There are no manuals, diagrams or notes, or the ones you have are years out of date.
• Nobody is sure what some parts of the system do.
• Developers you have approached do not want to touch it.
• You bought a company and its software came with it.

No documentation is the normal case

Very few business systems come with useful documentation. They were built under time pressure by people who knew how everything worked and saw no need to write it down. Then those people moved on. If this describes your system, you are in the majority, and it says nothing about the quality of the software underneath.

How an undocumented system is learned

• Get it running safely. A copy of the application and database is set up where nothing done to it can affect the live system.
• Read the database. The tables and their relationships show what the business tracks and how it fits together.
• Follow the main tasks. Enter an order, run the month-end, print the invoice, and trace what the code does at each step.
• Talk to the users. They know what the system is supposed to do, and which parts they have learned to avoid.
• Write it down. A map of the system, its rules and its weak points, in plain English.

Making it safe to change

The first changes to an unfamiliar system are the risky ones. We reduce that risk in a set order: put the code under version control so every change can be undone, set up a test copy, add checks around the parts we are about to touch, and only then start fixing and improving. Early work is deliberately small. Confidence in the system is built before anything large is attempted.

What you get at the end of the assessment

A plain report on what you have: what the system does, what it is built with, what condition the code and database are in, where the risks are, and what we would do first. You can use it to make decisions whether or not you go on to work with us.

How Keene Systems handles it

1. We collect what exists. Code, database, server access and anything written down.
2. We assess the system in a safe copy. Nothing is changed on the live system.
3. We report in plain English. Condition, risks and options.
4. We stabilize, document and then improve. In that order.

The next step is a short, no-pressure conversation. Book a call with Lance Keene or use the form on this page.