Data modernisation

Most data estates were not designed. They accumulated. A warehouse from one era, a lake from another, half a migration that stalled, and a great deal of business logic living in spreadsheets nobody will admit to.

Modernisation goes wrong in a predictable way. It starts with a platform decision, becomes a two year programme, and delivers nothing anybody outside the technology function can point at. The alternative is to start from the decisions the business needs to make and work backwards, which turns the same programme into a sequence where something useful lands every quarter.

What usually needs fixing

Nobody owns anything. Three systems disagree and there is no arbiter, so every number becomes a negotiation. This is almost never a technical problem. It is an accountability problem that technology gets blamed for.

The migration stalled halfway. You are paying for the old platform and the new one, running reconciliation between them, and the business case assumed the old one would be switched off eighteen months ago.

Quality is assumed rather than measured. There is no test, no threshold and no alert, so data problems surface in a leadership pack rather than in a pipeline.

The architecture followed a vendor roadmap rather than the business model. Cost scales with volume while value scales with decisions, and those two curves diverge quietly until someone notices the bill.

Nothing has ever been decommissioned. Every system ever built is still running because switching one off requires knowing who uses it, and nobody does.

How I approach it

Backwards from the decisions. An estate is only as good as the questions it can answer reliably, so we start with the questions the business actually asks, work out which sources genuinely feed them, and fix those first.

That reordering matters more than any platform choice. It means the first thing delivered is something a business owner recognises, which is what buys the political capital to keep going.

Modernisation that starts with the platform produces a better platform. Modernisation that starts with the decisions produces a better business.

Where I am careful

Migration timelines are almost always optimistic because they price the move and not the parallel running, the reconciliation, the exceptions and the retraining. I would rather give you a longer number you can plan around than a shorter one that fails in month seven.

I am also sceptical of full rebuilds. They are occasionally right and usually the expensive way to avoid a difficult conversation about ownership.

What you get

• An estate map with a named owner against every source that matters, validated with the owners rather than assumed.
• A data quality baseline, measured rather than asserted, with thresholds you can alert on.
• A target architecture that fits the business model and the budget, not a reference diagram from a vendor.
• A migration sequence, costed, with dependencies made explicit and a first delivery inside a quarter.
• A decommissioning list, which is usually the part that pays for the work.
• A build or buy position on each component, with the third option honestly priced.

How this connects

Data modernisation is gate three of the 7D method. It is worth doing on its own, but it pays considerably more when the objective above it is settled first, because that is what tells you which parts of the estate matter and which can wait.

If you are unsure whether this is your blocker, the free gate check takes about four minutes and will tell you.