I have sat in rooms at three of Canada's largest insurers watching people work around systems that were built before some of their colleagues were born. These are not corner-case environments. They are the mainstream of Canadian insurance delivery.
The question people ask is why. Why is an industry with billions in annual premium still running on platforms that predate the internet? The answer is not laziness or ignorance. The answer is that replacement is genuinely hard, and the organizations that have tried to do it quickly have often paid a steep price.
A core insurance administration system is not a piece of software. It is a crystallization of decades of business decisions. Every rate, every rule, every product variant, every exception, every reporting obligation that has ever been enacted is encoded somewhere in that system. Often in ways that no one alive fully understands anymore.
When you replace a system like that, you are not just replacing code. You are reverse engineering thirty years of institutional knowledge and then rebuilding it in a different architecture. That process is long, expensive, and fragile. The failure rate for large core system replacement programs in Canadian financial services is not something the industry publishes, but anyone who has been in the room knows it is high.
The alternative to full replacement is incremental modernization. Build a layer on top of the legacy system. Add a modern front end. Move specific functions onto new platforms while keeping the core running. This is the path most Canadian insurers have taken.
The problem is that legacy systems were not designed to be incrementally modernized. The interfaces are not clean. The data models are proprietary. The integration points require custom work every time. Each incremental addition creates a new dependency, which makes the next addition harder.
I have worked on programs where the incremental approach was the right call, and I have worked on programs where it compounded the problem. The difference was usually whether the organization had a real architecture strategy or just a series of project-level decisions that added up to nothing coherent.
Incremental modernization without an architecture strategy is just legacy accumulation with better front ends.
One thing that has actually accelerated modernization in Canadian insurance is regulatory change. FINTRAC KYC requirements, CRS reporting obligations, and anti-money-laundering frameworks do not care whether your system can accommodate them. They have deadlines. If you want to keep selling insurance in Canada, you figure it out.
I delivered multiple compliance-driven platform changes during my time in the industry. The interesting thing about compliance programs is that they create a forcing function that pure efficiency arguments do not. When the regulator sets a date, the conversation about whether to invest in modernization becomes much shorter.
Three things separate the modernization programs that work from the ones that fail.
First, the business case has to be honest. Programs that are funded on optimistic assumptions about timeline and cost almost always fail. Programs that are funded on realistic assumptions, with appropriate contingency, have a much better track record. The pressure to understate costs to get approval is real. Resisting that pressure requires courage at the sponsor level.
Second, the scope has to be controlled. Every legacy modernization program I have seen go off the rails got there the same way: the scope grew because the program became a vehicle for adding new capability rather than replacing existing capability. Replacement and enhancement are different programs. Running them simultaneously is how you get a program that takes five years and delivers neither well.
Third, the data migration has to be treated as a program in its own right. Data migration is where most legacy programs lose time and quality. The data in a legacy insurance system has accumulated over decades. It is inconsistent, incomplete, and encoded in formats that do not map cleanly to modern schemas. Treating data migration as a workstream within a larger program is almost always insufficient.
The industry will modernize. It is already happening. But it will happen slowly and expensively, which is the only way it can happen when the systems being replaced are the ones keeping policies in force for millions of Canadians.