Many modernisation projects start with a big plan and a vendor presentation. The first month is better spent on something less exciting: writing down what the old system actually does, what it touches and who understands it.
This article is for a technology or operations lead who has just been given the job of "doing something about" an old system. It describes a four-week inventory and how to use it to pick one small, useful result before any larger decision.
Why an inventory comes first
Old systems grow by addition. A report was added for finance, a nightly file export for a partner, a field that means something different in each department. Nobody has the whole picture, and the person who built the oldest parts may have left years ago.
If you plan the replacement without that picture, the new system will miss things that nobody remembered until the day they stopped working. A short inventory is cheap, and it turns "we think it does this" into a list you can check.
Week 1: modules
List what the system does in the words users use, not in technical names. For each function write one line: what it is for, who uses it, how often.
Typical entries are "creates quotes", "prints delivery notes", "month-end export for accounting". Ask users to show you, not to describe it; a ten-minute screen share often reveals a step nobody mentioned. Include small things such as a scheduled job, an email the system sends, or a spreadsheet that people fill in because the system cannot.
Do not try to be complete in week one. A list of twenty to forty lines is normal for a mid-sized system, and you will add to it later.
Week 2: data
For each module note where its data lives and what it is called. You need to know:
- which database or files hold the important records (customers, orders, products, stock);
- which data exists only in this system and nowhere else;
- which fields are filled in by hand, and which are known to be unreliable;
- how it is backed up, and whether anyone has tried to restore it.
The last point is the one most often skipped. A backup that has never been restored is a hope, not a safeguard. If you cannot find out in week two, write it down as an open question and give it an owner.
Week 3: integrations
Draw the connections as a simple list: what sends data to the system, what takes data from it, and how. Common forms are file exports, a shared database, an email, a manual copy from one screen to another, or a direct interface to another program.
For each connection note the other side (a department, a supplier, another application), how often it runs, and what happens when it fails. The manual connections matter as much as the technical ones. "Anna copies the totals into the spreadsheet every Friday" is an integration, and it is exactly the kind that disappears when Anna is away.
Week 4: people and owners
Go back through the list and give every item an owner. Two kinds of owner are useful:
- a business owner, who can say whether the function is still needed and what "correct" looks like;
- a technical contact, who knows how it works or can find out.
Where nobody fits, write "no owner". Do not fill the gap with a name to make the list look tidy. An item with no owner and no documentation is a risk, and it should be visible on the page you give to management.
Also mark every item that depends on one person. If that person is unavailable for a month, which functions are in trouble? This is often the most persuasive part of the whole exercise, because it needs no technical knowledge to understand.
Choosing one small win
With the inventory in hand, pick one improvement that you can finish before the month ends or soon after. A good first win has four properties:
- Visible. Users or colleagues notice it, for example a report that no longer needs manual work or a failure that stops happening.
- Small. Two to three weeks of effort at most, without changing the core of the system.
- Reversible. If it goes wrong, you can go back to how things were.
- Useful for what comes next. It teaches you something about the system or removes a risk you found, such as documenting an undocumented export or testing a restore.
Examples that usually fit: automating one manual copy step from the integrations list, writing down and testing the restore procedure, adding a second person who knows a critical job, or removing a function that nobody has used for a year after the business owner agreed.
Avoid the temptation to choose the most annoying problem. The most annoying problem is often the hardest. The aim of the first win is to show that change is possible and safe, and to build trust for the larger steps. If you later need to decide which part of the system to rework first, see how to choose the first module.
The one-page summary
At the end of the month, produce a single page with:
- the number of modules, data stores and integrations you found;
- the items with no owner or no documentation;
- the items that depend on one person;
- the small win you completed or have under way, and what it showed;
- two or three questions that need a management decision.
Keep it short. The point is that a manager can read it in five minutes and see that the work was real. The detailed list stays with the team as a working document and should be updated when something changes.
What not to do in the first month
- Do not start rebuilding. Without the inventory you will rebuild the wrong things.
- Do not promise a date or a cost for the full replacement. You do not yet know enough.
- Do not interview only managers. The people who use the system daily know things nobody else does.
- Do not let the inventory become a documentation project that never ends. Four weeks, then stop and decide.
Where to go next
After the first month you know what you have, where the risks are and that a change can be made safely. That is a much better position to talk to a supplier or to plan the next step. For the wider picture of what often blocks modernisation and which cheap fixes help, read legacy systems before AI agents, and for the general case for modernising, see modernize legacy systems. If the inventory shows that a tool depends on its author, the one-page handover is a good small win in itself.
Sources
- Our related articles linked above.
- The four-week structure and the criteria for a small win are a working practice, not a standard; adapt them to your system and team. Examples are illustrative. No client results or market figures are claimed in this article.