Sanchet Pachpute is CIO of New York Life Insurance Company, where he leads platform modernization for Institutional Annuities.
Every large insurance carrier eventually reaches the same crossroads: The core systems that ran the business for 20 or 30 years no longer keep pace with today’s needs. Policy administration, finance, compliance and distribution all depend on platforms built and extended long before “cloud-native” or “API-first” entered anyone’s vocabulary. The natural next step is to modernize, often by moving to a modern, vendor-supplied platform. That step is also where most modernization programs quietly get into trouble—and in annuities and life insurance, the trouble runs deeper than in most industries because a single policy can stay on the books for 30 or 40 years, quietly outliving two or three generations of the very systems meant to administer it.
The problem isn’t choosing a new platform. It’s everything that has to keep talking to it. A mid-sized carrier can easily have a dozen or more systems feeding data into and out of its core administration platform: accounting and valuation, treasury and tax, client systems, payment processors, clearing houses and a cluster of regulatory feeds—sanctions screening, anti-money-laundering checks, state-specific reporting—each with its own format and its own tolerance for error. Pricing and Valuation calculations in particular can’t simply be rerun after the fact; if the feed supplying them lags or drops a field during a cutover, the ripple shows up in financial statements, not a support ticket. Each connection was typically built one at a time, over years, by different teams, using whatever protocol was convenient at the time. Swap the core platform underneath all of that, and you’re not migrating one system—you’re renegotiating dozens of point-to-point relationships at once.
This is where modernization budgets and timelines quietly die. In my experience, an early discovery effort on a platform migration turned up business logic—validation rules, data transformations, exception handling—buried in integration code for years because nobody had a cleaner place to put it. Untangling that logic from the old platform and correctly re-implementing it in the new one became its own drawn-out effort, layered on top of the migration everyone had actually budgeted for.
The Integration Problem Is The Real Migration
The fix I’ve found most effective is architectural rather than tactical: Build a dedicated integration layer that sits between internal systems and any external platform, and treat it as permanent infrastructure rather than temporary migration scaffolding. Instead of connecting each internal feed directly to a vendor platform, every feed connects to this layer once. The layer owns the business logic, the validation rules, the transformations and the routing decisions. The vendor platform on the other side becomes, from the layer’s point of view, replaceable—a set of inbound and outbound extracts rather than a system with its own hooks into your business rules.
A handful of design choices make this hold up in practice. Business logic should belong to the company, not the vendor, so a future platform change never requires re-authoring rules from scratch. The layer itself should run on standard protocols and data contracts rather than any one platform’s proprietary interfaces, so replacing the vendor underneath it stays an integration exercise, not a re-architecture. Sensitive policyholder and financial data should stay inside infrastructure the company controls for as long as possible, moving out only through encrypted, narrowly scoped channels when it must. And the components doing the work—validation, transformation, reconciliation, monitoring—are worth building as reusable modules from day one, so the next modernization program doesn’t start from zero.
Build For The Next Platform, Not Just This One
None of this is free. Standing up and governing a layer like this takes dedicated ownership—someone has to maintain it and resist the temptation to let one-off exceptions creep back in, the same way they crept into the old point-to-point connections. For a smaller carrier without the scale to justify a dedicated integration team, that discipline can outweigh the benefit, at least until the next major platform change is already on the horizon.
It pays off well beyond the initial migration. When a vendor changes its API, sunsets a feature or gets acquired and re-platformed—none of which is rare in insurance technology—the disruption stays contained at the layer’s vendor-facing edge instead of rippling back through a dozen internal systems. In practice, that means a vendor-side change that once would have forced a reintegration effort across several internal systems gets absorbed almost entirely within the layer itself, with the rest of the business never noticing it happened.
For any CIO staring down a core platform migration, the lesson isn’t “build exactly this layer.” It’s to ask a harder question before signing the next vendor contract: not whether the platform meets today’s needs but what it will cost to leave it in five years—and whether that cost is being designed down now, while there’s still time, or discovered later, when there isn’t.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
