Why Insurance Data Migrations Get Cancelled at 70%

Legacy modernisation is the project every insurer knows they need and dreads starting — because everyone has heard the horror story. The migration that ran for three years, consumed a fortune, and got quietly cancelled at 70% complete, leaving the old system running and a lot of expensive lessons.

These failures aren't random or unlucky. They follow patterns, and the patterns are avoidable once you can see them. Here's why insurance data migrations get cancelled — and how to not be the next cautionary tale.

1. The big bang

The most common killer. The plan is to build the complete replacement, pick a weekend, cut everything over at once, and turn off the old system.

It fails for a reason that's baked into the approach: you cannot fully test a replacement for a system nobody completely understands. Decades-old policy systems are full of undocumented behaviour — a rating quirk, a batch job that silently fixes bad data, an edge case that fires for one product in one state. A big-bang cutover discovers all of it on Monday morning, in production, with customers watching. When too much breaks at once, there's no path but rollback — and after enough rollbacks, cancellation.

The fix: phased migration. Move one product line, one state, one workflow at a time, each with a rollback path. Every slice shrinks the blast radius of the next.

2. Lift-and-shift

"Just move it as-is, we'll modernise later." It sounds prudent and it's a trap. Copy a 1990s data model into a modern platform and you get a 1990s model with a cloud bill — every original problem intact, plus a migration to justify. "Later" never comes; the org books the win and moves on.

Sometimes the cancellation is subtler here: the migration technically completes, delivers none of the promised value because nothing was remodelled, and the next initiative — the one that needed a clean foundation — gets cancelled instead.

The fix: remodel during the migration, or accept you never will.

3. Underestimating the archaeology

Timelines are built assuming the work is moving data. The actual work is discovering what the old system does — and nobody fully knows, because the people who did have often left. Teams hit undocumented rule after undocumented rule, the timeline blows out, confidence erodes, and a project that's massively over schedule with no end in sight becomes a cancellation candidate.

The fix: budget for discovery explicitly. Treat reconciliation mismatches as the mechanism for surfacing hidden rules, not as bugs to rush past. Expect archaeology and plan for it.

4. Skipping the parallel run

Under schedule pressure, the parallel run — both systems running on real traffic, outputs compared — is the first thing cut. It's also the single most important risk mitigation in the whole project. Skip it and you cut over without evidence the new system matches the old, discover the divergences in production, and trigger the rollback-to-cancellation spiral.

The fix: never cut the parallel run to hit a date. It is the de-risking. Two extra months of parallel running is cheaper than a cancelled programme.

5. Treating it as purely technical

Many migrations are staffed and planned as technology projects, when the hardest problems are organisational: three teams disagreeing on what "active policy" means, no one empowered to decide, ownership undefined. These aren't solved by engineers. They stall in meetings, the project loses momentum, and momentum loss is how large programmes quietly die.

The fix: resolve ownership and definitions as part of the migration, with senior sponsorship empowered to make the calls that unblock the technical work.

6. No incremental value

A migration designed to deliver everything at the end delivers nothing until then — which means eighteen months of cost with no visible return. When budgets tighten or leadership changes (and over a multi-year programme, they will), a project that hasn't shown value is the easiest thing to cut.

The fix: sequence for early, visible wins. Get data out into a lakehouse early (read-only, low risk) so analytics and AI unlock before the risky core migration even starts. Value delivered is political capital, and political capital is what carries a long programme through leadership changes.

7. Losing the thread

Migrations get framed as "move off the old system," and that framing quietly kills them — because nobody actually wants to move off a system for its own sake. When the goal is completing a move, the project optimises for finishing, hits the inevitable hard parts, and — since "finishing a move" is nobody's passion — loses the will to push through.

The fix: keep the real goal visible. Nobody wants a migration; they want what it unlocks — underwriting that sees the whole customer, real-time fraud, 90% STP, AI that ships. Teams anchored to the outcome make better decisions and find the will to finish, because the prize is worth it.

The pattern behind the patterns

Read the seven back and a theme emerges: almost none of these failures are about the destination technology. They're about approach — phasing, remodelling, discovery, parallel running, organisation, incremental value, and keeping sight of the point.

That's genuinely good news. It means a successful migration isn't gated on a genius architect or the perfect platform. It's gated on doing ordinary things in the right order and refusing the tempting shortcuts. The insurers whose migrations succeed aren't luckier. They just didn't take the seven exits to cancellation.

We run phased, value-first insurance data migrations designed to avoid exactly these failure modes — 200+ of them across the modern lakehouse. More at IntelliBooks.