How estates grow
No organisation sets out to run three document systems, two ticketing tools and a dozen spreadsheets that behave like databases. Estates grow one reasonable decision at a time: a department buys a tool to meet an urgent need, a merger brings its own systems, a pilot becomes permanent because nobody switched it off.
The result is familiar. Licence costs that are hard to attribute. Integrations that break when one system is upgraded. Security teams patching software that a handful of people use. And data scattered so widely that a simple question, such as how many active customers we have, gets several different answers. Application rationalisation is the disciplined work of deciding what to keep, what to combine and what to retire.
Step one: build an honest inventory
You cannot rationalise what you cannot see. Start with a single inventory of every application, including the unofficial ones. For each, record its business owner, technical owner, the capabilities it supports, its users, its integrations, where its data lives and what it costs to run. Expect the first version to be incomplete; it improves as people realise it will be used to make decisions.
Keep the inventory in a shared, structured place rather than a spreadsheet passed around by email. It will be needed again, and an inventory that is maintained becomes the foundation of good architecture governance rather than a one-off report.
Step two: map applications to capabilities
Next, describe what the organisation does, independent of the software it uses: manage customers, issue invoices, handle complaints, manage documents. Map each application to the capabilities it supports. Overlaps become visible immediately, and so do gaps. This capability view is also the language that lets business and technology leaders discuss the estate together.
Done well, this exercise also clarifies ownership. Every capability should have a named business owner, and every application should have someone accountable for its cost and its risk. Where nobody will put their name to an application, that is often the first sign it can go.
Step three: assess each application
Assess every application on two axes: business value and technical health. Value covers how well it supports its capabilities and how much users rely on it. Health covers supportability, security, integration quality and cost. A simple scoring, agreed in advance, keeps the discussion grounded. The classic outcomes follow from where each application lands:
Involve users in the assessment. The people who use an application every day know which features matter and which workarounds hide its weaknesses, and their support is essential when the time comes to change.
- Keep: high value, good health; invest and make it the standard.
- Improve: high value, poor health; modernise or replatform.
- Consolidate: overlapping function; migrate users to the chosen standard.
- Retire: low value; plan an orderly exit and archive the data.
- Replace: a capability poorly served by everything available; choose a new solution, ideally open source.
Steps four and five: plan, then execute and govern
Step four is a roadmap. Sequence changes by benefit and dependency, not by enthusiasm. Retiring an application is rarely only a technical act: users need training on the replacement, data needs migrating or archiving, and contracts need ending on time. Quick wins, such as unused licences and duplicate tools with few users, build momentum and fund the harder work. Every figure in the business case should be labelled as measured or estimated; mixing them is how rationalisation programmes lose credibility.
Step five is execution with governance. Retire carefully: archive data in an open, readable format before switching anything off, because data should stop being metered, not be deleted. Then put a light gate in front of new purchases, so every new application is checked against the capability map before it is bought. Without that gate, the estate quietly grows back.
Open source helps at every stage. Consolidating onto open platforms removes licence costs from the equation, and owning the software means the next rationalisation exercise is a choice rather than a negotiation with a vendor.