Core Insurance Modernization: Build vs Buy

Part 5 finished the tour of the core systems. Every insurance modernization eventually reaches the same fork, and it’s usually where the most heat and the least light get generated: do we buy a packaged core suite or build our own? This part argues something slightly heretical — that the build-versus-buy decision matters far less than the room thinks, because the thing that actually determines whether the program succeeds is the same on both paths.

The decision, stated fairly

There are honest cases for each side, and pretending otherwise is how vendors sell.

The case for buy. Packaged policy-admin, claims, and rating suites give you a supported platform, a roadmap someone else maintains, out-of-the-box capability across lines, and an escape from the talent cliff for the underlying technology. For capability that’s genuinely commoditized — standard lines, standard workflows — reinventing it in a custom build is hard to justify. Buy converts an open-ended engineering commitment into a configuration-and-integration effort plus a license.

The case for build. Where your products, rating, or workflows are a real source of differentiation, a packaged suite forces an uncomfortable choice: conform to its model and lose the edge, or customize it so heavily that you’ve built a bespoke system inside someone else’s framework — with all the cost of building and none of the control. Build tends to win when the logic is the competitive advantage, when you need to move faster than a vendor’s release cycle, and when integration into a specific ecosystem is the dominant constraint.

Most real programs land in the middle: buy some components, build others, and discover that the integration between them is its own significant body of work. That’s a legitimate answer, not a failure to decide.

Why the decision matters less than it seems

Here’s the uncomfortable part. Whichever path you choose, the hardest and riskiest work is identical — and it’s not the work the build-versus-buy debate is about.

Both paths have to migrate the same thing: decades of undocumented rating, underwriting, and claims rules, plus the in-force book and the open claims, out of the legacy core and into the new one. Buying a suite does not recover those rules for you. It hands you a configuration surface and says “now express your products, your filed rates, and your forty years of accreted special cases in here.” If you don’t actually know what those rules are — and per Parts 3 and 4, most carriers don’t, completely — you’ll configure the suite from an incomplete understanding and discover the gaps in production. The transformation-failure base rate from Part 1 (Boston Consulting Group, September 2023: up to 70% of digital transformations fail to deliver on their objectives) doesn’t distinguish between build and buy. It punishes the same mistake on both.

So the purchase order doesn’t remove the migration risk; it relocates it into configuration and data migration, where it’s easy to underestimate precisely because the platform looks “ready.”

The execution that works on either path

This is the legacy-modernization discipline applied to the build-vs-buy fork: the platform decision changes what you’re migrating into, not how you migrate safely.

1. Recover the rules first, regardless of destination. Whether you’ll configure a suite or write code, you need the rating, underwriting, and claims rules as living specs before you start — because both the configuration and the build are only as correct as your understanding of what they must reproduce.
2. Slice by capability. Migrate one product, line, or claim type at a time into the new core — configured or built — rather than the whole book at once.
3. Prove parity before cutover. Run the new core (suite or custom) in the shadow of the legacy system and compare outputs — premiums, decisions, reserves, payments — exactly. Parity validation doesn’t care whether the new system was bought or built; it cares whether it behaves identically. A packaged suite has to clear the same bar.
4. Migrate the book gradually, with rollback, behind a facade, with the legacy core running until its last slice retires.

Framed this way, the build-vs-buy decision becomes what it should be: a sourcing and architecture choice about the destination, made on its merits — total cost, differentiation, vendor fit, in-house capability — and decoupled from the question of whether the migration will succeed. The migration succeeds or fails on rule recovery and parity, not on the logo on the platform.

How to actually make the call

Once you’ve accepted that execution dominates, the sourcing decision gets simpler, because you can evaluate it on its real merits instead of as a proxy for “which path is safe.” A few questions that tend to settle it:

• Is this capability a differentiator or a commodity? Differentiating rating, products, or workflows argue for build (or heavy configuration you control); commodity capability argues for buy.
• Where do you want the maintenance burden and the talent dependency to sit? Buy moves the platform’s upkeep and the underlying skills to a vendor — which is genuinely valuable against the talent cliff, but trades one dependency for another.
• How much will you customize? A suite you customize beyond a threshold stops being “buy” in any meaningful sense; you’re building inside someone else’s constraints, often the worst of both. If your honest answer is “we’ll customize heavily,” price it as a build.
• What’s the integration surface? If the dominant cost is wiring the new core into a specific ecosystem of channels, data, and downstream systems, that work is similar either way and may favor whichever option integrates more cleanly with what you already run.

These are real trade-offs with no universal answer, which is the point: it’s a sourcing decision, and it should be argued as one. What it should not be is a decision people treat as the determinant of success and then execute carelessly.

The hybrid reality

Most large insurers don’t end up purely on one side. They buy a modern policy-admin or claims suite for some lines and keep or build bespoke logic for others; they wrap a packaged rating engine but build the underwriting workbench around it; they run new business on a new platform while the legacy core handles run-off. That hybrid is a legitimate destination — but it adds a cost the pure-play options don’t: the seams between bought and built components become integration contracts you own, with their own undocumented behavior risk over time. The slice-by-slice discipline handles a hybrid naturally, because each slice can target whichever component is right for it, but the parity bar and the rule recovery apply across all of them equally.

Where AI changes the economics

AI-accelerated discovery shifts the build-vs-buy math in a specific way: it makes the rule recovery that both paths require dramatically cheaper and faster — roughly 10× faster than manual review at the analysis step. That matters most for the buy path, where teams routinely underbudget the “express our rules in the suite’s configuration” work because they never priced the cost of figuring out what those rules are. With the rules recovered as specs up front, both the configuration effort and the custom build start from knowledge instead of archaeology, and the parity gate is the same evidence standard either way. AI does the reading; people make the sourcing call and own the parity decision.

Not automatically safer, and not always now

Two honest caveats. First, “buy” is not automatically safer because it’s vendor-supported — a heavily customized suite can become its own legacy system, with its own undocumented configuration and its own lock-in, in a surprisingly short time. Second, the right answer is sometimes “neither, not yet”: if the legacy core is stable, supported enough, and not blocking anything, the disciplined move may be to capture the rules now (against the talent cliff) and defer the platform decision until there’s a real driver. We’d rather help you make that call clearly than push a build or a buy you don’t yet need.

Where this leads

Build or buy, the new core still has to satisfy the regulators — and a lot of programs either over-rotate on compliance or under-plan for it. Part 7, Insurance Modernization & Regulatory Compliance, separates what regulation actually requires from the modernization myths around it, and shows how the rules-as-specs approach makes compliance easier to evidence rather than harder.