Legacy insurance technology consumes 60 to 70% of insurer IT budgets on maintenance alone, blocks digital initiatives, and prevents AI deployment. This post explains the three costs of legacy systems, what modern platforms deliver differently, the three modernisation approaches available, and how to build the board-level business case for investment. All currency figures are in NOK.
68% on Maintenance. 32% for Everything Else. Three Initiatives Failed Last Year.
The slide on screen shows a pie chart. The CTO has been working on this presentation for three weeks. Of the insurer's total annual technology budget, 68% is consumed by maintaining and operating systems that were last significantly updated between 2008 and 2014. A policy administration platform purchased in 2009. A claims management system implemented in 2012. A finance reporting stack built on a database version that the vendor stopped supporting in 2021. The remaining 32% of the budget is available for new capability development.
The CFO asks a straightforward question: what did we deliver with the 32% last year? Five digital initiatives were approved by the board in the prior financial year. Two completed. One is delayed by 14 months. Two were cancelled. All three failures had the same root cause: the legacy core system could not support the API integration the new capability required. The team spent NOK 4.8 million on integration work before either cancellation. Neither produced a line of new capability.
The CFO looks at the pie chart again. The question she asks is not about the 68%. It is about whether the 68% is the reason the 32% keeps failing.
Key Figures
| Figure | What it means |
|---|---|
| 60–70%[1] | Of total IT budget at legacy-dependent insurers consumed by maintaining existing systems. This proportion has grown year on year since 2020 as maintenance costs on ageing infrastructure compound and vendor support contracts escalate. |
| 68%[2] | Of large insurance technology implementation projects on legacy-constrained infrastructure run over budget or over time, with the average overrun being 40% of the original estimate. The primary cause in 61% of overruns is integration complexity with the legacy core. |
| 6–18 months[1] | Average time to launch a new insurance product on a legacy core system, versus 4 to 8 weeks on a modern API-first platform. The difference is not development effort. It is the time required to integrate with a system not designed to accommodate change. |
| 3.2×[2] | Higher total cost of ownership over five years for insurers maintaining legacy core systems versus those that have migrated to modern platforms, when the full cost of maintenance, integration workarounds, and delayed digital initiatives is included. |
| 74%[1] | Of European insurers in a 2024 survey said core system modernisation was among their top three technology investment priorities. Only 31% had a funded modernisation programme in place — the gap reflects perceived implementation risk, not lack of awareness of the cost. |
The Three Costs of Legacy Insurance Technology
Cost 1: Direct maintenance
The cost that appears most clearly on the budget is the direct maintenance line: vendor support contracts, infrastructure operation, database licensing, and internal staff time consumed by keeping the legacy system running. At 60 to 70% of the total IT budget, this is not a marginal cost. It is the dominant cost of the technology function. And it grows. Vendor support contracts escalate annually. Infrastructure costs rise as the hardware ages. Staff capable of maintaining code written in legacy languages become harder to find and more expensive to retain.
The insurer that spent NOK 42 million on technology last year and allocated NOK 28 million of it to legacy maintenance is not making a choice between maintenance and innovation. It is experiencing a structural constraint that leaves NOK 14 million for everything else: new products, digital channels, AI capability, regulatory technology. When three of those initiatives fail due to legacy integration problems, the NOK 14 million available for innovation is partly consumed by failed integration attempts rather than delivered capability.[1]
Cost 2: Opportunity cost
The opportunity cost of legacy insurance technology is harder to put on a slide but larger in commercial terms than the direct maintenance cost. It shows up in three places. First, digital initiatives that cannot complete: the customer portal that cannot support real-time policy changes because the core system does not expose a write API; the distribution partnership that cannot go live because the partner requires a real-time underwriting response and the legacy system only processes in batch; the claims status update feature that cannot be built because the claims data is only available 24 hours after each processing cycle.
Second, AI deployment that stalls: an insurer that purchases an AI fraud detection platform, completes the vendor integration, and then discovers that the legacy claims system delivers data in a format requiring six weeks of transformation work before the model can be trained. The AI platform cost is sunk. The transformation cost is unplanned. The deployment timeline extends by four months. Third, competitive positioning: a technology-native MGA that launches a new commercial lines product in six weeks because its platform was built API-first from day one competes directly for the same broker panel as an established carrier whose product launch requires 14 months of integration work.
Cost 3: Competitive cost
The competitive cost accumulates slowly and becomes visible suddenly. An insurer that has deferred modernisation for five years does not notice the time-to-market gap widening year by year. It notices when a technology-native competitor launches an embedded insurance product in a distribution channel the legacy-dependent carrier cannot access, or when a broker platform rationalises its panel and removes carriers that cannot support real-time API connectivity.
For Nordic market insurers, the competitive cost is amplified by the digital infrastructure expectations of the Norwegian and Scandinavian market. Norwegian consumers and brokers operate in one of the most digitally advanced economies in Europe. An insurer whose distribution and customer-facing systems cannot match the digital capability of the banking and fintech platforms their customers use every day faces a structural disadvantage that grows as digital adoption accelerates.
What a Modern Insurance Platform Delivers Differently
The contrast between legacy insurance technology and a modern insurance platform is not primarily about user interface or feature set. It is about architecture. The capabilities that matter for digital transformation, AI deployment, and competitive distribution are architectural capabilities that cannot be retrofitted onto a system designed before those requirements existed.
| Capability | Legacy core system | Modern insurance platform |
|---|---|---|
| API architecture | Batch-only or proprietary connectors; no REST APIs | API-first; full REST and event-driven integration capability |
| Deployment model | On-premise servers; manual release cycles | Cloud-native; continuous deployment; auto-scaling |
| Data access | Overnight batch extracts; no real-time data | Real-time data streams; live portfolio visibility |
| AI integration | Not possible without middleware layer | Native AI/ML integration; pre-built model connectors |
| Time to launch new product | 6–18 months average[1] | 4–8 weeks average |
| Maintenance as % of IT budget | 60–70% | 25–35% |
| Change delivery | 18–24 months for major changes | Continuous delivery; weeks for major changes |
Three Modernisation Approaches
Insurance core system modernisation does not require a single approach. Three options are available, each with a different risk profile, timeline, and cost structure. The right choice depends on the specific state of the legacy system, the organisation's risk appetite, and the urgency of the capability gaps the modernisation is intended to address.
| Approach | What it means | Timeline | Risk | Best when |
|---|---|---|---|---|
| Full replacement | Replace the legacy core with a modern platform end to end | 24–48 months | High | Legacy system is at end of life; vendor support ending; debt is unmanageable |
| Strangler fig | Incrementally replace components while keeping the legacy core live; route traffic to new components as they go live | 18–36 months per major component | Medium | Core system is stable but blocking; business cannot absorb full replacement risk |
| Automation layer | Deploy AI and workflow automation above the legacy core; modernise the process without replacing the system | 8–16 weeks per workflow | Low | Legacy system holds clean data; process is the problem not the platform; speed to value is critical |
The automation layer approach deserves specific attention because it is the fastest path to measurable outcome and the lowest-risk entry point to modernisation. An insurer that deploys AI and workflow automation above its legacy core can address specific process problems, free up innovation budget by reducing manual handling costs, and build the business case for a more substantial modernisation investment from the evidence base that the automation deployment produces.
For Norwegian insurers, Finanstilsynet's expectations for technology risk management and outsourcing oversight apply to all three modernisation approaches. Core system replacement and cloud migration both require documented risk assessments and ongoing vendor oversight under Finanstilsynet's outsourcing guidelines. The automation layer approach, where the legacy system remains in place, typically carries a lower outsourcing risk profile. Specific regulatory requirements for Norwegian technology modernisation programmes should be verified with qualified Norwegian legal counsel.[3]
How to Build the Business Case for Modernisation
A modernisation business case that focuses only on the cost of the new platform will not pass a board that has seen technology investments fail before. The business case must quantify the cost of not modernising alongside the cost of the investment, and present the total cost of ownership comparison over five years for each option: maintain the status quo, deploy an automation layer, implement a strangler fig migration, or complete a full replacement.
The status quo cost calculation includes: current annual maintenance spend projected forward with annual escalation (typically 8 to 12% per year for legacy support contracts), the cost of digital initiatives that will fail or be delayed, and the estimated competitive cost of the time-to-market gap. The investment cost calculation includes: implementation cost, integration cost, data migration cost, ongoing platform licence and operation, and the internal change management cost. The five-year total cost of ownership comparison typically shows the modernisation investment recovering its cost in year three or four, with cumulative savings materialising from year three onwards as maintenance costs decline and innovation budget is freed up.[1][2]
Frequently Asked Questions
Our legacy system works — why would we replace something that is not broken?+
The question is not whether the legacy system works. It is what it costs to keep it working, and what it prevents the business from doing. A legacy system that consumes 68% of the IT budget on maintenance, blocks three of five digital initiatives per year, and cannot support real-time API connectivity is working in the sense that policies are being administered and claims are being processed. It is not working in the sense that the business requires. The compounding cost of deferral — escalating maintenance contracts, accumulating integration workarounds, widening competitive gaps — typically exceeds the modernisation investment within three to four years.[1][2]
What is the strangler fig modernisation pattern and how does it work in practice?+
The strangler fig pattern is an incremental modernisation approach in which new system components are built alongside the existing legacy core, and traffic is routed to the new components as each one is completed and validated. The legacy system is not replaced in a single programme. It is incrementally decommissioned as each component is superseded. In insurance, it is most commonly applied to policy administration components: the customer portal, the product configuration layer, and the distribution API layer are replaced first, while the core rating and transaction engine remains in place until the surrounding components are stable.[2]
How do we manage the data migration risk in a core system replacement?+
Data migration is the highest-risk component of a core system replacement. The risk is not the migration itself but the data quality in the legacy system: incomplete records, inconsistent field values, undocumented business rules embedded in the data structure, and historical data that does not map cleanly to the new system's schema. A data quality assessment of the legacy system should be the first step in any replacement programme, before vendor selection or implementation planning. The assessment typically takes 8 to 12 weeks. Phased migration — starting with new business and running parallel systems for in-force policies during the transition — reduces the risk of a single cutover.[2]
What does an insurance platform migration look like for a mid-size Nordic insurer?+
For a mid-size Norwegian insurer with a single core platform and a personal lines book of 150,000 to 300,000 policies, a full insurance platform migration typically takes 18 to 28 months from vendor selection to full cutover, with a budget in the range of NOK 45 million to NOK 120 million depending on the complexity of the product set and the degree of customisation required. Finanstilsynet's outsourcing notification requirements apply where the new platform is hosted and operated by a third-party vendor. A parallel running period of 3 to 6 months for in-force policies is standard practice. Specific regulatory requirements should be verified with qualified Norwegian legal counsel.[3]
How do we measure the ROI on a modernisation investment to present to the board?+
The ROI framework has three components. First, maintenance cost reduction: the difference between the current annual maintenance spend and the projected annual cost of operating the modern platform, compounded over five years. Second, initiative delivery improvement: the value of digital initiatives that will complete on the modern platform but failed or were cancelled on the legacy core, quantified as revenue or cost reduction per initiative. Third, time-to-market value: the premium and revenue impact of launching new products in 4 to 8 weeks rather than 6 to 18 months, applied to the insurer's product pipeline. The five-year net present value of these three components against the modernisation investment cost typically shows positive return from year three.[1][2]
Can we deploy AI on top of our legacy system without replacing it?+
Yes, in many cases. The prerequisite is that the legacy system holds clean, structured data that can be accessed by an AI or automation layer through a database connection, a file export, or a middleware integration. If that condition is met, AI workflow automation can address specific process problems — submission processing, fraud scoring, claims triage, document generation — without touching the underlying system. The limitation is that AI capabilities that require real-time data access, real-time API responses, or event-driven triggers will be constrained by the batch processing architecture of most legacy cores. The automation layer approach delivers measurable value quickly and builds the evidence base for a more substantial modernisation investment.[2]
References
All statistics sourced from documented deployments and third-party research organisations. All currency figures in NOK. Links verified 2026. Click any citation to jump to its source.
Legacy insurance technology consumes 60 to 70% of insurer IT budgets on maintenance alone, blocks digital initiatives, and prevents AI deployment. This post explains the three costs of legacy systems, what modern platforms deliver differently, the three modernisation approaches available, and how to build the board-level business case for investment. All currency figures are in NOK.
68% on Maintenance. 32% for Everything Else. Three Initiatives Failed Last Year.
The slide on screen shows a pie chart. The CTO has been working on this presentation for three weeks. Of the insurer's total annual technology budget, 68% is consumed by maintaining and operating systems that were last significantly updated between 2008 and 2014. A policy administration platform purchased in 2009. A claims management system implemented in 2012. A finance reporting stack built on a database version that the vendor stopped supporting in 2021. The remaining 32% of the budget is available for new capability development.
The CFO asks a straightforward question: what did we deliver with the 32% last year? Five digital initiatives were approved by the board in the prior financial year. Two completed. One is delayed by 14 months. Two were cancelled. All three failures had the same root cause: the legacy core system could not support the API integration the new capability required. The team spent NOK 4.8 million on integration work before either cancellation. Neither produced a line of new capability.
The CFO looks at the pie chart again. The question she asks is not about the 68%. It is about whether the 68% is the reason the 32% keeps failing.
Key Figures
| Figure | What it means |
|---|---|
| 60–70%[1] | Of total IT budget at legacy-dependent insurers consumed by maintaining existing systems. This proportion has grown year on year since 2020 as maintenance costs on ageing infrastructure compound and vendor support contracts escalate. |
| 68%[2] | Of large insurance technology implementation projects on legacy-constrained infrastructure run over budget or over time, with the average overrun being 40% of the original estimate. The primary cause in 61% of overruns is integration complexity with the legacy core. |
| 6–18 months[1] | Average time to launch a new insurance product on a legacy core system, versus 4 to 8 weeks on a modern API-first platform. The difference is not development effort. It is the time required to integrate with a system not designed to accommodate change. |
| 3.2×[2] | Higher total cost of ownership over five years for insurers maintaining legacy core systems versus those that have migrated to modern platforms, when the full cost of maintenance, integration workarounds, and delayed digital initiatives is included. |
| 74%[1] | Of European insurers in a 2024 survey said core system modernisation was among their top three technology investment priorities. Only 31% had a funded modernisation programme in place — the gap reflects perceived implementation risk, not lack of awareness of the cost. |
The Three Costs of Legacy Insurance Technology
Cost 1: Direct maintenance
The cost that appears most clearly on the budget is the direct maintenance line: vendor support contracts, infrastructure operation, database licensing, and internal staff time consumed by keeping the legacy system running. At 60 to 70% of the total IT budget, this is not a marginal cost. It is the dominant cost of the technology function. And it grows. Vendor support contracts escalate annually. Infrastructure costs rise as the hardware ages. Staff capable of maintaining code written in legacy languages become harder to find and more expensive to retain.
The insurer that spent NOK 42 million on technology last year and allocated NOK 28 million of it to legacy maintenance is not making a choice between maintenance and innovation. It is experiencing a structural constraint that leaves NOK 14 million for everything else: new products, digital channels, AI capability, regulatory technology. When three of those initiatives fail due to legacy integration problems, the NOK 14 million available for innovation is partly consumed by failed integration attempts rather than delivered capability.[1]
Cost 2: Opportunity cost
The opportunity cost of legacy insurance technology is harder to put on a slide but larger in commercial terms than the direct maintenance cost. It shows up in three places. First, digital initiatives that cannot complete: the customer portal that cannot support real-time policy changes because the core system does not expose a write API; the distribution partnership that cannot go live because the partner requires a real-time underwriting response and the legacy system only processes in batch; the claims status update feature that cannot be built because the claims data is only available 24 hours after each processing cycle.
Second, AI deployment that stalls: an insurer that purchases an AI fraud detection platform, completes the vendor integration, and then discovers that the legacy claims system delivers data in a format requiring six weeks of transformation work before the model can be trained. The AI platform cost is sunk. The transformation cost is unplanned. The deployment timeline extends by four months. Third, competitive positioning: a technology-native MGA that launches a new commercial lines product in six weeks because its platform was built API-first from day one competes directly for the same broker panel as an established carrier whose product launch requires 14 months of integration work.
Cost 3: Competitive cost
The competitive cost accumulates slowly and becomes visible suddenly. An insurer that has deferred modernisation for five years does not notice the time-to-market gap widening year by year. It notices when a technology-native competitor launches an embedded insurance product in a distribution channel the legacy-dependent carrier cannot access, or when a broker platform rationalises its panel and removes carriers that cannot support real-time API connectivity.
For Nordic market insurers, the competitive cost is amplified by the digital infrastructure expectations of the Norwegian and Scandinavian market. Norwegian consumers and brokers operate in one of the most digitally advanced economies in Europe. An insurer whose distribution and customer-facing systems cannot match the digital capability of the banking and fintech platforms their customers use every day faces a structural disadvantage that grows as digital adoption accelerates.
What a Modern Insurance Platform Delivers Differently
The contrast between legacy insurance technology and a modern insurance platform is not primarily about user interface or feature set. It is about architecture. The capabilities that matter for digital transformation, AI deployment, and competitive distribution are architectural capabilities that cannot be retrofitted onto a system designed before those requirements existed.
| Capability | Legacy core system | Modern insurance platform |
|---|---|---|
| API architecture | Batch-only or proprietary connectors; no REST APIs | API-first; full REST and event-driven integration capability |
| Deployment model | On-premise servers; manual release cycles | Cloud-native; continuous deployment; auto-scaling |
| Data access | Overnight batch extracts; no real-time data | Real-time data streams; live portfolio visibility |
| AI integration | Not possible without middleware layer | Native AI/ML integration; pre-built model connectors |
| Time to launch new product | 6–18 months average[1] | 4–8 weeks average |
| Maintenance as % of IT budget | 60–70% | 25–35% |
| Change delivery | 18–24 months for major changes | Continuous delivery; weeks for major changes |
Three Modernisation Approaches
Insurance core system modernisation does not require a single approach. Three options are available, each with a different risk profile, timeline, and cost structure. The right choice depends on the specific state of the legacy system, the organisation's risk appetite, and the urgency of the capability gaps the modernisation is intended to address.
| Approach | What it means | Timeline | Risk | Best when |
|---|---|---|---|---|
| Full replacement | Replace the legacy core with a modern platform end to end | 24–48 months | High | Legacy system is at end of life; vendor support ending; debt is unmanageable |
| Strangler fig | Incrementally replace components while keeping the legacy core live; route traffic to new components as they go live | 18–36 months per major component | Medium | Core system is stable but blocking; business cannot absorb full replacement risk |
| Automation layer | Deploy AI and workflow automation above the legacy core; modernise the process without replacing the system | 8–16 weeks per workflow | Low | Legacy system holds clean data; process is the problem not the platform; speed to value is critical |
The automation layer approach deserves specific attention because it is the fastest path to measurable outcome and the lowest-risk entry point to modernisation. An insurer that deploys AI and workflow automation above its legacy core can address specific process problems, free up innovation budget by reducing manual handling costs, and build the business case for a more substantial modernisation investment from the evidence base that the automation deployment produces.
For Norwegian insurers, Finanstilsynet's expectations for technology risk management and outsourcing oversight apply to all three modernisation approaches. Core system replacement and cloud migration both require documented risk assessments and ongoing vendor oversight under Finanstilsynet's outsourcing guidelines. The automation layer approach, where the legacy system remains in place, typically carries a lower outsourcing risk profile. Specific regulatory requirements for Norwegian technology modernisation programmes should be verified with qualified Norwegian legal counsel.[3]
How to Build the Business Case for Modernisation
A modernisation business case that focuses only on the cost of the new platform will not pass a board that has seen technology investments fail before. The business case must quantify the cost of not modernising alongside the cost of the investment, and present the total cost of ownership comparison over five years for each option: maintain the status quo, deploy an automation layer, implement a strangler fig migration, or complete a full replacement.
The status quo cost calculation includes: current annual maintenance spend projected forward with annual escalation (typically 8 to 12% per year for legacy support contracts), the cost of digital initiatives that will fail or be delayed, and the estimated competitive cost of the time-to-market gap. The investment cost calculation includes: implementation cost, integration cost, data migration cost, ongoing platform licence and operation, and the internal change management cost. The five-year total cost of ownership comparison typically shows the modernisation investment recovering its cost in year three or four, with cumulative savings materialising from year three onwards as maintenance costs decline and innovation budget is freed up.[1][2]
Frequently Asked Questions
Our legacy system works — why would we replace something that is not broken?+
The question is not whether the legacy system works. It is what it costs to keep it working, and what it prevents the business from doing. A legacy system that consumes 68% of the IT budget on maintenance, blocks three of five digital initiatives per year, and cannot support real-time API connectivity is working in the sense that policies are being administered and claims are being processed. It is not working in the sense that the business requires. The compounding cost of deferral — escalating maintenance contracts, accumulating integration workarounds, widening competitive gaps — typically exceeds the modernisation investment within three to four years.[1][2]
What is the strangler fig modernisation pattern and how does it work in practice?+
The strangler fig pattern is an incremental modernisation approach in which new system components are built alongside the existing legacy core, and traffic is routed to the new components as each one is completed and validated. The legacy system is not replaced in a single programme. It is incrementally decommissioned as each component is superseded. In insurance, it is most commonly applied to policy administration components: the customer portal, the product configuration layer, and the distribution API layer are replaced first, while the core rating and transaction engine remains in place until the surrounding components are stable.[2]
How do we manage the data migration risk in a core system replacement?+
Data migration is the highest-risk component of a core system replacement. The risk is not the migration itself but the data quality in the legacy system: incomplete records, inconsistent field values, undocumented business rules embedded in the data structure, and historical data that does not map cleanly to the new system's schema. A data quality assessment of the legacy system should be the first step in any replacement programme, before vendor selection or implementation planning. The assessment typically takes 8 to 12 weeks. Phased migration — starting with new business and running parallel systems for in-force policies during the transition — reduces the risk of a single cutover.[2]
What does an insurance platform migration look like for a mid-size Nordic insurer?+
For a mid-size Norwegian insurer with a single core platform and a personal lines book of 150,000 to 300,000 policies, a full insurance platform migration typically takes 18 to 28 months from vendor selection to full cutover, with a budget in the range of NOK 45 million to NOK 120 million depending on the complexity of the product set and the degree of customisation required. Finanstilsynet's outsourcing notification requirements apply where the new platform is hosted and operated by a third-party vendor. A parallel running period of 3 to 6 months for in-force policies is standard practice. Specific regulatory requirements should be verified with qualified Norwegian legal counsel.[3]
How do we measure the ROI on a modernisation investment to present to the board?+
The ROI framework has three components. First, maintenance cost reduction: the difference between the current annual maintenance spend and the projected annual cost of operating the modern platform, compounded over five years. Second, initiative delivery improvement: the value of digital initiatives that will complete on the modern platform but failed or were cancelled on the legacy core, quantified as revenue or cost reduction per initiative. Third, time-to-market value: the premium and revenue impact of launching new products in 4 to 8 weeks rather than 6 to 18 months, applied to the insurer's product pipeline. The five-year net present value of these three components against the modernisation investment cost typically shows positive return from year three.[1][2]
Can we deploy AI on top of our legacy system without replacing it?+
Yes, in many cases. The prerequisite is that the legacy system holds clean, structured data that can be accessed by an AI or automation layer through a database connection, a file export, or a middleware integration. If that condition is met, AI workflow automation can address specific process problems — submission processing, fraud scoring, claims triage, document generation — without touching the underlying system. The limitation is that AI capabilities that require real-time data access, real-time API responses, or event-driven triggers will be constrained by the batch processing architecture of most legacy cores. The automation layer approach delivers measurable value quickly and builds the evidence base for a more substantial modernisation investment.[2]
References
All statistics sourced from documented deployments and third-party research organisations. All currency figures in NOK. Links verified 2026. Click any citation to jump to its source.
How legacy technology is costing insurers money and what modern platforms are doing about it