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. That ₹40 is an undocumented business rule you just discovered — safely, in a report, instead of in production three months after cutover.

The teams that chase every mismatch to root cause ship successfully. The teams that write off "small" differences find out later they weren't small; they were a pattern.

3. Lift-and-shift is a trap that feels like pragmatism

"Just move it as-is, we'll modernise later" sounds risk-averse. It isn't. Copy a 1990s schema into Snowflake and you have a 1990s schema with a cloud bill — every downstream problem intact, plus a migration you now have to justify.

"Later" doesn't come. The organisation books the win and moves on. Remodel during the migration or accept you never will.

4. The customer key is the whole game

If we could force one decision on every migration, it'd be this: resolve identity early.

Every project where entity resolution came first went well. Every project where it was deferred ("we'll unify customers in phase 2") ended up with a beautiful platform that still couldn't answer who the customer was — which is the question the business actually cares about.

It's not glamorous, it's genuinely hard, and it's the difference between a data platform and an expensive copy of your problems.

5. Nobody has ever regretted the parallel run

Not once. In 200+ migrations, no team has said "we ran both systems too long."

Plenty have said the opposite — usually while explaining an outage. The parallel run is the risk mitigation. Cutting it to hit a date is trading two months of patience for a two-year reputation problem.

6. Data quality is never as good as the last audit said

Ask any carrier about data quality and you'll hear a number from a study done a while ago. Measure it fresh and it's always worse — because quality decays continuously, and the audit was a snapshot of a moving thing.

The fix isn't a bigger cleanup project. It's continuous scoring, so decay is visible instead of discovered.

7. The blocker is organisational more often than technical

The hardest problem on most migrations isn't a schema. It's that three teams disagree about what "active policy" means, and each has a system encoding their definition.

You cannot solve that with a pipeline. Someone senior has to decide, and everyone has to live with it. Migrations stall in meetings far more often than in code.

8. Everyone wants real-time; almost nobody needs it everywhere

Ask what needs to be real-time and the answer is "everything." Ask what decision changes if data is seconds old instead of hours old, and the list collapses to three or four genuine cases — FNOL, fraud, quoting.

Build those in real time. Batch the rest. Every unnecessary stream is a permanent operational tax.

9. Governance retrofits don't exist

You cannot document lineage you didn't capture. You cannot produce a decision record you never wrote. Teams that treat governance as a phase-2 concern discover, when the regulator asks, that phase 2 was impossible.

With the NAIC bulletin now live across 23 US jurisdictions and the EU AI Act landing through August 2026, this has moved from "good practice" to "the reason your AI can't go live."

10. The migration was never the point

The last and most important one. Nobody wants a migration. They want what it unlocks: underwriting that sees the whole customer, fraud detection that runs at FNOL instead of overnight, STP at 90% instead of 15%, and AI that ships instead of stalling.

Teams that keep that framing make better decisions — they remodel properly, they build the customer key, they instrument lineage — because they're building a foundation, not completing a move. Teams that treat it as a move optimise for finishing, and finish with nothing worth having.

The through-line

Read the list again and one thing repeats: almost nothing that decides a migration is about the cloud platform. It's identity, discipline, patience, and refusing to defer the unglamorous work.

Which is good news, really. It means success isn't gated on a vendor decision or a genius architect. It's gated on doing ordinary things in the right order — which any team can choose to do.

200+ migrations across Snowflake, Databricks, BigQuery, Redshift and Synapse — including the insurance data foundations AI runs on. More at IntelliBooks.