You took over. Maybe you bought the business, maybe you inherited the department, maybe you were promoted into it. Along with everything else came software that runs a meaningful part of daily operations.
There is no documentation. The person who built it left before you arrived. Your staff know which buttons to press, and nothing about what happens after that. When you ask how something works, you get a description of the ritual, not the mechanism.
This is a common position and it is more tractable than it feels. The order of operations matters, though, and the intuitive order is wrong.
Do not start with the code
The instinct is to get a developer to look at the software. That comes later. Start with ownership, because it is urgent, it is time-limited, and you can do it yourself.
Make a list of every account the business depends on and establish two facts about each: whose name it is in, and whose card pays for it.
- The domain name. Where yourcompany.com is registered. This is the most important item on the list — losing it takes your website and your email simultaneously, and recovering one registered in a departed person’s name can take weeks.
- Hosting. The server everything runs on.
- The code repository. Where the software and its change history live. Sometimes it exists only on the server.
- DNS. The settings pointing your domain at your server. Frequently a different account from the domain registration.
- Email, payment processing, text messaging, anything with a recurring charge. Go through the bank statement line by line. Recurring charges are a reliable map of your dependencies, and they surface services nobody remembered.
Anything not in the company’s name and not on the company’s card is something you do not currently control. Fix those first, starting with the domain.
There is a timing element here. If the previous owner or developer is still reachable, that window is short and it narrows quickly. Use it for specific requests — account names, supplier lists, who built which part — rather than open-ended conversations. Specific questions get answered; general ones get postponed.
Then find out what you are running
Now the technology, and the first step costs nothing.
Ask the hosting company which versions the account runs and when each stops receiving security fixes. Two answers, one support ticket, and between them they tell you whether you have inherited something maintained or something abandoned.
If it reports versions that stopped receiving fixes years ago, that is not a crisis today. It does tell you the system has not been maintained for a while, which shapes everything that follows.
What the missing documentation actually costs
Worth being clear about, because it is easy to treat as a filing problem rather than a business risk.
Undocumented software cannot be handed over. Any developer you hire spends their first weeks working out what they are looking at, at your expense, and that cost repeats with every new person. It cannot be safely changed, because nobody knows what depends on what — so changes get avoided, and the system slowly stops matching how the business now operates. It cannot be honestly assessed. And it cannot be sold well: when you eventually sell the business, a buyer’s technical review of an undocumented system reduces your price or stalls the deal.
The last one surprises people. Documentation is not administrative tidiness. It is part of the asset value.
What is actually recoverable
More than you would expect.
The change history in the code repository, if it exists, is a running record of every modification and often why. It reconstructs a great deal.
The code itself is a complete description of what the system does — unambiguous, if slow to read. That is what an audit is: someone reading it and writing down what is there in language you can use.
Your longest-serving staff hold real knowledge, even though they will tell you they are not technical. They know which screens matter, which reports are wrong and get corrected by hand, which parts everyone avoids. That is genuinely valuable and it is not written anywhere.
And the supplier list from the bank statement tells you what the system connects to, which is half of understanding it.
What a proper audit produces
Five business days of someone reading the system, the server and whatever history survives. The output is a written document in plain language: what exists, what it connects to, what condition it is in, what is dangerous, what it would cost to fix each item, ranked by what each is costing you now.
For someone who has inherited a business, this document does several jobs at once. It is your map. It is what makes your next developer productive in days instead of months. It is what you answer a customer’s security questionnaire from. And it is part of what you hand a buyer when you sell.
You own it outright. If you take it to a completely different firm, it is immediately useful to them. That is the point — the aim is that you stop depending on any single person’s memory, ours included.
The audit is $2,400 fixed and the fee comes off the cost of the work if you proceed. If the honest conclusion is that the system is in reasonable shape, you get that in writing. Everything is priced here.
About replacing it
You may be wondering whether to scrap it and buy something off the shelf. Sometimes that is genuinely correct, and you should find out rather than assume either way.
What you cannot do is decide before you know what the current system does. Inherited systems are full of behavior that looks arbitrary and exists because of a real constraint — a pricing rule for one large customer, a workaround for a supplier’s format, a step that exists for a regulatory reason nobody remembers. Those details are the expensive part to rediscover, and businesses that replace before mapping tend to find them one at a time, in production, for eighteen months.
Map first. Then decide. If replacement is the right answer, we will tell you so and you will have paid for the document that proves it.