Why do inherited IT systems feel so unmanageable?

Because they grew without a map. Nobody sat down ten years ago and designed what you're now running. The CRM was chosen by an operations manager who left in 2021. The warehouse integration was built by a contractor whose number nobody has. Finance runs on a package that predates everyone in the building, held together by a spreadsheet only one person understands.

None of this is incompetence. It's history. Every system was a sensible answer to the question of the day. The trouble is that the questions changed, the people moved on, and the answers stayed - undocumented, unowned, and increasingly tangled into each other.

That's why the estate feels unmanageable: not because it's broken, but because nobody can see the whole of it. You can't say what would happen if you switched something off. You can't say whether the monthly software bill is buying anything. You can't even say, with confidence, how many systems you've got.

Don't start by changing things. Start by seeing them.

New accountability creates pressure to act. Something visible, something decisive - a new system, a big migration, a supplier cleared out. Resist it.

Changing an estate you can't see is how outages happen. Pull out one ageing tool and you discover, at the worst possible moment, that three processes quietly depended on it. The businesses that get this wrong don't fail through inaction - they fail through confident action in the dark.

Looking is cheap. Guessing is expensive. The map comes before the moves, and everything else in this article depends on that order.

What should an IT estate review actually cover?

Get everything into one view. For every system the business runs on, you want five things written down:

• What it is and what it does - in one plain sentence, not a product description.

• Who owns it - a named person, not a department. If the answer is "nobody", that's a finding.

• What it costs - licences, hosting, support, and the renewal date.

• What depends on it - the systems it feeds, the processes it sits under, the people who'd notice if it vanished.

• Who set it up and why - if anyone still knows.

Include the unofficial estate too: the scheduling spreadsheet, the shared inbox that runs customer service, the personal Dropbox with the CAD files in it. That's usually where the real dependencies hide.

This doesn't need to be a sixty-page audit. A clear register with those five columns beats a glossy report every time. What matters is that it's complete, and that it's honest.

Expect surprises. Every estate mapped this way turns up the same things: two tools doing one job, licences still billing for people who left years ago, and at least one process the whole business depends on that lives in a single person's head.

Are your legacy systems really the biggest risk?

Usually not - and this is where most inherited-estate thinking goes wrong. Age is not the same as risk.

A ten-year-old accounts package that does its job, has a supplier behind it, and is understood by three people might be the most stable thing you own. A two-year-old integration that nobody documented and everybody is afraid to touch is a bigger exposure, however modern it looks.

So sort the estate by dependency, not by age. At Segmentum this segmentation is the core of how we work - everything in the estate lands in one of three groups:

• Foundational - the business stops if this fails. Core systems, the data underneath them, security, backups.

• Structural - the connections and workflows between systems. Where the friction, the retyping between systems, and the workarounds live.

• Iterative - everything that could be improved but isn't holding anything else up.

Sorted this way, an inherited estate stops being a fog of equally worrying unknowns. It becomes a short list of real exposures, a medium list of friction, and a long list that can safely wait.

Fix in order: stabilise, then streamline, then improve

With the estate mapped and sorted, the order of work writes itself.

Stabilise the foundational risks first. The backup no one has ever tried restoring. The system out of vendor support that holds customer data. The process that depends entirely on one person staying healthy and employed. None of this is glamorous, and all of it comes first.

Then take the structural friction out. The data that gets retyped between three systems. The month-end that takes a week because nothing talks to anything. This is where the visible wins live - time back, fewer errors, faster answers.

Then improve. New capability, better tooling, the interesting projects. They land far better on foundations that hold.

The discipline is saying no to step three until steps one and two are done. Most inherited estates got into this state precisely because the exciting work kept jumping the queue.

How do you stop the estate drifting again?

Ownership. The estate drifted because no one owned the whole - systems arrived one decision at a time and nobody held the map.

Three habits fix that, and none of them are heavy:

• Every system has a named owner. One person who can say what it's for, what it costs, and when it renews.

• The register stays current. Anything added, changed or retired gets recorded - a line, not a form.

• Decisions get written down. One paragraph on why a system was chosen. The next person to inherit this estate will thank you.

An hour a quarter reviewing the register with your leadership team is enough. That's the entire overhead of never being in the dark again.

You don't need to have built it to lead it

You don't need to have built the estate to take control of it. You need to see it clearly, in one place, sorted by what actually matters. That's what a Discovery delivers: a complete picture of what you inherited and a clear order to act in. From there, it stops being something that happened to you and becomes something you lead.