Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on.

And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy?

You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have.

The problem a warehouse solves

Warehouses solve location. Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts.

But notice what that fixes: it fixes where the data is. It doesn't touch what the data means, whether it's trustworthy, or whether the records refer to who you think they do.

And those were your actual problems.

The four things it didn't fix

1. Identity. The biggest one. You copied four unlinked customer records from four systems into one database. They're still four unlinked records — now co-located. Co-location isn't resolution. "Show me everything about this person" is still unanswerable, because nothing ever decided that these four records are one person.

2. Quality. Roof age was blank on 30% of records in the source system. It's blank on 30% of records in the warehouse. ETL moved the gaps faithfully. You now have high-availability, well-governed, beautifully-modelled missing data.

3. Meaning. Three teams have three definitions of "active policy," each encoded in their own system. Your warehouse now contains all three, in different tables, silently disagreeing. Every report that touches policy counts produces a slightly different number, and everyone quietly picks the one they like.

4. Timeliness. The warehouse loads nightly. Your fraud detection and quote decisions need signals in seconds. So the use cases that needed the data most still can't use it, and they route to humans exactly as before.

Why this keeps happening

Because the warehouse project's success criteria were about the warehouse.

"Are all source systems integrated?" Yes. "Do loads complete within the window?" Yes. "Is it modelled in a star schema?" Yes. Project delivered, everyone congratulated.

Nobody's criterion was: can underwriting now answer a question they couldn't answer before? Because that would have exposed that integration was never the hard part.

It's the same mistake as buying an AI model before fixing the data — solving the visible, purchasable problem instead of the real, tedious one.

What actually turns a warehouse into a foundation

The good news: you did the boring half. Extraction, pipelines, orchestration, a place to put things — that's real, and you don't have to redo it. What's missing is the layer that makes it mean something.

1. Resolve identity. Entity resolution across the records you've already centralised, and a stable customer key that survives change. Do this first; everything else compounds off it. Your warehouse is actually a good place to do it — the data is finally in one query.

2. Measure quality, per field, continuously. Not an audit — a score, tracked, with thresholds. You cannot fix what you've never measured, and "the data is messy" is not a measurement.

3. Agree the definitions, then encode them once. Pick one meaning for "active policy." This is an organisational fight, not a technical one, and it needs someone senior to end it. Then define it once, in one place, and let everything read from that.

4. Add a real-time path for the signals that need it. Not everything. FNOL, fraud, quoting. CDC or streaming alongside the nightly batch, landing in the same platform so it joins to your history.

5. Instrument lineage now. You'll need it for the NAIC bulletin and the EU AI Act, and you cannot retrofit lineage you never captured. Do it while you're in there.

The reframe

Stop thinking of the warehouse as finished infrastructure. Think of it as the first of five layers, and you built one.

That reframe changes the conversation with your board, too. "The warehouse didn't deliver, we need another platform" is a losing pitch — and wrong. "The warehouse is the foundation; here are the four specific things on top of it that unlock underwriting and AI, and here's what each costs" is a fundable, honest plan that respects the money already spent.

Your warehouse didn't fail. It just did the part everyone could see, and the part nobody could see is where the value was hiding.

We turn existing warehouses into genuine foundations — identity, quality, semantics, real-time, and lineage. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Snowflake or Databricks for Insurers? An Honest Comparison

It's the question in every insurance data platform decision, and it generates more heat than insight: Snowflake or Databricks? Here's an honest answer from having migrated a lot of both. Short version: they're both excellent, the gap is narrower than either vendor implies, and the decision matters far less than what you do next. But there are real differences, and your workload should pick. Where each genuinely leads Snowflake is stronger when your centre of gravity is SQL analytics. Reporting, actuarial analysis, regulatory extracts, BI over structured policy and claims data. It's operationally calmer — less to tune, fewer knobs, and your existing SQL people are productive on day one. Separation of storage and compute means the finance team's month-end doesn't fight the actuaries' model run. For a carrier whose data is mostly relational and whose consumers are mostly analysts, it's the shorter path. Databricks is stronger when your centre of g...
Read more

What 200+ Cloud Migrations Taught Us About Insurance Data

Over 200 cloud migrations, patterns emerge. Not the ones in the vendor case studies — the ones you only see from inside, at 2am, when the reconciliation doesn't balance. Here's what we've actually learned about insurance data. Some of it is uncomfortable. 1. The estimate is always wrong in the same direction Every migration takes longer than planned, and almost never because of the technology. It's because of what you find: a rating rule nobody documented, a batch job that silently corrects bad data at 2am, a product variant that exists only in one state. The work isn't moving data. It's discovering what the old system actually does — which nobody knows in full, because the people who knew have retired. Budget for archaeology, not just engineering. 2. Every reconciliation mismatch is a gift When your new premium calculation disagrees with the legacy system by ₹40 on 300 policies, the instinct is to treat it as a bug to squash quickly. Don't. Tha...
Read more

From Mainframe to Lakehouse: How to Modernize a 30-Year-Old Policy System Without Downtime

Ask any insurance CTO what keeps them from modernizing, and you'll rarely hear "budget" or "talent." You'll hear something closer to fear: the policy administration system has been running since the 1990s, it processes every quote, endorsement, and renewal the company makes, nobody who wrote it still works there — and the business cannot go dark for even an afternoon. So the migration gets deferred. Another year passes. Meanwhile every AI initiative, every customer-experience project, and every analytics roadmap quietly starves, because they all need data that's trapped inside that system. Here's the thing: the fear is rational, but the conclusion isn't. Migrating a legacy policy core without downtime is well-trodden ground. It just requires abandoning the approach everyone instinctively reaches for. Why the big-bang cutover fails The instinct is to build the replacement, pick a weekend, flip the switch, and pray. This fails for a predict...
Read more