Begin with the service, not the software list
Choose an important service and ask the people running it which applications they use. Include specialist tools and the informal spreadsheets that carry essential work. Record what each system contributes, rather than relying only on a product category.
For a distributed organisation, the same product may be used differently by several teams. Conversely, different products may support nearly identical tasks. Looking at the service makes those relationships easier to understand and gives the inventory a purpose beyond collecting technical names.
Find the person who can verify the record
A register needs owners as well as entries. Identify who understands the application’s use, who maintains it and who can confirm important information. These may be different people.
Start with existing records, then ask the appropriate staff to review gaps and inconsistencies. Mark an unknown value clearly instead of guessing. A useful inventory can show where knowledge is missing. That is more valuable than an apparently complete spreadsheet filled with assumptions that no one is prepared to stand behind.
Draw the connections that affect decisions
Show which systems exchange information and which services depend on them. Keep the first diagram understandable to the people making the decision. Detailed supporting information can sit behind it where necessary.
A proposed replacement may affect a report, another application or a manual step that is not obvious from the product list. Ask staff to test the map against a normal working day. The diagram should help someone explain the effect of a change before that change becomes an implementation problem.
Prioritise using an agreed basis
Possible concerns include ageing products, unclear ownership, duplicated functions and difficult handovers. Agree which factors matter to the organisation and how they will be assessed. Avoid treating every overlap as waste or every old application as an immediate replacement candidate.
Combine the findings into a practical sequence. Some issues may need better documentation or a small process change. Others may justify a detailed replacement assessment. The roadmap should explain why an item appears early or late and what further evidence is needed before committing to it.
Keep the inventory alive
Decide when records will be reviewed and what changes trigger an update. A new application, a different owner or a major service change should have a clear path back into the inventory. Train the responsible team using real examples.
The outputs can include application and infrastructure registers, dependency maps, a lifecycle review and a prioritised roadmap. Their value depends on continued use. Build the maintenance routine around the organisation’s normal decisions so the inventory remains a working reference rather than a document left behind after an initial review.
Explore our Application inventories and modernisation planning, related services and Choose business systems around the decisions people make.

