Cloud migration in insurance fails most often not from poor execution but from inadequate preparation: undiscovered integration dependencies, data quality problems, and unbudgeted regulatory compliance work. This post explains the three migration approaches, the integration mapping step most programmes skip, the DORA and Finanstilsynet obligations that apply, and what successful deployments show.
34 Integration Failures. 7 Months Delayed. NOK 8.4 Million Unbudgeted. All Preventable.
The migration programme launched in January with a 12-month timeline and a clear scope: lift-and-shift the policy administration system from the insurer's on-premise data centre to a major cloud infrastructure provider. The vendor had done this before. The internal team was experienced. The board had approved the budget. By July, the programme had paused.
The technical lead presents the situation to the steering committee at 09:30 on a Tuesday morning. Of the 87 integration points between the policy administration system and its downstream applications — the claims system, the finance platform, the distribution APIs, the customer portal, the document management system — 34 do not function correctly in the cloud environment. Some fail intermittently. Some fail consistently. Three produce data integrity errors that the team has not yet been able to reproduce in the test environment.
The remediation is unplanned. It was not in the original scope because nobody mapped the integration dependencies in detail before the migration began. The assumption was that a lift-and-shift would carry the integrations across unchanged. It did not. The revised timeline is 19 months from January, not 12. The additional cost is NOK 8.4 million, unbudgeted. The board does not ask about the cloud. It asks about the preparation.
Key Figures
| Figure | What it means |
|---|---|
| 72%[1] | Of insurance cloud migration programmes that overrun budget or timeline cite undiscovered integration complexity as the primary cause — not technology failure, vendor underperformance, or scope change. The integrations were present in the legacy environment. They were not mapped before migration began. |
| 38%[2] | Average reduction in infrastructure operating cost achieved by insurers that completed cloud migrations successfully, measured 24 months post-migration, driven by elastic scaling and consumption-based pricing replacing fixed data centre contracts. |
| 6 weeks[1] | Recommended minimum duration for integration dependency mapping before any cloud migration programme begins, based on documented deployment experience across mid-size insurer migrations. Programmes that skip or compress this step are 3.4 times more likely to encounter significant post-migration integration failures. |
| 61%[2] | Of European insurers in a 2024 survey had moved at least one core workload to cloud infrastructure, up from 34% in 2021. The acceleration reflects both cost pressure and the increasing cloud readiness of insurance-specific platform vendors. |
| NOK 8–25m[1] | Typical range of unplanned remediation costs incurred by mid-size insurers that begin cloud migrations without completing integration dependency mapping and data quality assessments. |
The Three Cloud Migration Approaches
Insurance cloud transformation does not mean the same thing to every insurer or every system. The approach chosen determines the complexity, cost, timeline, and ultimate value of the migration programme. Selecting the right approach before committing to a vendor or a timeline is the decision that shapes everything that follows.
| Approach | What it means | Timeline | Risk | Best when |
|---|---|---|---|---|
| Lift-and-shift | Move the existing system to cloud infrastructure without code changes | 4–10 months | High — integration issues surface post-migration | Speed is critical; system is stable; full rewrite is not viable |
| Re-platform | Move with targeted optimisations for the cloud environment; partial code changes | 10–18 months | Medium — optimisations introduce scope creep | System is broadly sound but has specific cloud compatibility issues |
| Cloud-native re-architecture | Rebuild the system for cloud-native operation: microservices, containers, event-driven | 24–42 months | Lower long-term; highest during transition | Legacy is at end of life; full capability transformation is the goal |
The lift-and-shift approach is the most commonly chosen and the most frequently problematic. Its appeal is speed and cost. Its failure mode is integration: systems that functioned correctly on-premise do not automatically function correctly in a cloud environment where integrations rely on network protocols, latency assumptions, or infrastructure configurations that differ between environments. The 34 integration point failures in the opening scene are a lift-and-shift failure, not a cloud infrastructure failure.
Integration Dependency Mapping: The Step Most Programmes Skip
Integration dependency mapping is the process of identifying every system that sends data to or receives data from the system being migrated, documenting how each integration works at the protocol and data format level, and assessing whether each integration will function correctly in the target cloud environment. It is the most important preparatory step in any cloud migration programme — and the one most consistently compressed or skipped.
The reason it gets skipped is that it is not glamorous work. It does not produce a visible deliverable until it reveals a problem. A six-week integration mapping exercise that uncovers 34 problematic integration points does not feel like a productive six weeks at the start of a programme. It is. Those six weeks prevent the NOK 8.4 million remediation cost and the seven-month programme delay.[1]
A proper integration dependency map covers: every system the migrating application connects to; the protocol and data format of each connection; the latency and throughput requirements; whether each connection relies on infrastructure features (IP addresses, network zones, certificate stores) that will change in the cloud environment; and the fallback behaviours of each downstream system if the connection is temporarily unavailable during migration. The output is a dependency register with a cloud-readiness assessment for each integration point. Any integration assessed as cloud-unready is a migration risk that must be addressed before the programme begins, not after.
Data migration risk
The data migration risk in a cloud migration programme is not primarily a technology risk. It is a data quality risk: incomplete records, inconsistent field values, undocumented business rules embedded in the data structure, and historical data that does not map cleanly to the schema expected by the cloud environment. A data quality assessment of the policy administration system should be conducted before any migration programme begins. Migrating incomplete or inaccurate data at speed does not produce a clean system faster. It produces an inaccurate system faster.
For Norwegian insurers, the GDPR as implemented through the EEA Agreement requires that personal data of Norwegian policyholders remains within the EEA unless an adequacy decision applies to the destination jurisdiction. A cloud migration that routes policy data through infrastructure outside the EEA without a valid transfer mechanism is a GDPR compliance failure, not just a technical oversight. Data residency requirements should be confirmed with the cloud provider before contract signature.
Regulatory Requirements for Cloud-Hosted Insurance Infrastructure
Cloud migration in insurance triggers regulatory obligations that are not present in an on-premise deployment. DORA, which came into force across the EU and EEA in January 2025, establishes specific requirements for cloud outsourcing by financial institutions. Finanstilsynet's guidance on outsourcing and third-party risk management applies to Norwegian insurer cloud deployments. The obligations are not optional and they are not addressed by the cloud provider's standard compliance certifications.
| Requirement | Framework | What it means for cloud migration |
|---|---|---|
| Outsourcing risk assessment | DORA Art. 28 / Finanstilsynet | Formal risk assessment required before contracting cloud provider; ongoing monitoring obligations apply throughout the contract period |
| Concentration risk | DORA Art. 29 / Finanstilsynet | Dependency on a single major cloud provider must be assessed; exit strategy required for each critical workload hosted |
| Data residency | GDPR / Finanstilsynet | Personal data of Norwegian/EU policyholders must remain within EEA unless an adequacy decision applies to the destination jurisdiction |
| Operational resilience testing | DORA Art. 24–25 | Cloud-hosted critical systems must be included in the TLPT (Threat-Led Penetration Testing) programme |
| Exit and portability | DORA Art. 30 | Contract must include exit provisions; data portability in standard format; transition assistance obligations on the provider |
The concentration risk requirement deserves specific attention for Norwegian insurers. DORA Article 29 requires financial institutions to assess and manage the risk of dependency on a single ICT third-party provider. For an insurer that migrates its policy administration, claims management, and finance systems to the same major cloud provider, the concentration risk is not theoretical. A cloud provider outage affecting all three systems simultaneously would constitute a significant operational resilience failure. The risk assessment must document this dependency and the mitigation measures in place. Specific regulatory interpretations for Norwegian cloud migration programmes should be verified with qualified Norwegian legal counsel.[3][4]
Measured Outcomes from Successful Deployments
Frequently Asked Questions
Our data is too sensitive to move to a public cloud environment.+
Major cloud providers operate financial services-grade infrastructure with security certifications — ISO 27001, SOC 2 Type II, PCI DSS — that typically exceed the security posture of on-premise data centres at mid-size insurers. The sensitivity of the data is a reason to evaluate the cloud provider's security controls rigorously, not a reason to remain on-premise by default. The relevant questions are: does the provider's data residency option keep policyholder data within the EEA; does the provider's security architecture meet Finanstilsynet's expectations; and does the contract meet DORA Article 30 exit and portability requirements? If yes to all three, the sensitivity concern is addressed.[3][4]
How long does integration dependency mapping take and can it run in parallel with migration planning?+
Integration dependency mapping takes a minimum of four to six weeks for a mid-size insurer with 50 to 90 integration points, and eight to twelve weeks for larger carriers with 100 or more connections. It can and should run in parallel with migration planning, vendor selection, and contract negotiation. It cannot run in parallel with migration execution: the output of the mapping exercise must inform the migration scope and approach before execution begins. Programmes that begin migration execution before completing dependency mapping are accepting the risk of discovering integration failures after go-live at a significantly higher remediation cost.[1]
What is the DORA concentration risk requirement and how does it apply to our cloud vendor selection?+
DORA Article 29 requires financial institutions to assess and manage the systemic risk of dependency on a single ICT third-party provider. For insurers, this means documenting the proportion of critical business functions that depend on a single cloud provider, assessing the impact of a prolonged outage, and implementing mitigation measures — which may include multi-cloud architecture, on-premise fallback for the most critical processes, or contractual resilience commitments from the provider. The concentration risk assessment must be maintained as a living document and reviewed when new workloads are added to the provider.[3]
How do we handle regulatory data retention requirements when migrating historical policy records?+
Insurance regulatory data retention requirements — typically 5 to 10 years for policy records and claims history depending on jurisdiction — apply to data in the cloud environment in the same way they apply on-premise. The migration plan must address: how historical records will be migrated (full migration versus archive-in-place for older records), how the retention schedule will be enforced in the cloud environment, and how data subject access requests and regulatory audit requests will be fulfilled from cloud-hosted records. Norwegian data retention requirements under forsikringsvirksomhetsloven and GDPR apply regardless of where the data is hosted.[4]
What should the exit provision in our cloud vendor contract specify?+
Under DORA Article 30, the exit provision must specify: the format in which all data will be exported on contract termination (structured, machine-readable formats in standard schemas); the minimum notice period for termination; the transition assistance the provider will give, including the duration and scope; the cost of exit, including data export costs; and the provider's obligations regarding data deletion after the exit period. Provisions that specify 'best efforts' or leave format and cost unspecified do not meet the DORA standard. The exit plan should be negotiated as part of the initial contract, before the insurer has accumulated dependency on the provider.[3]
What is the typical budget for a cloud migration programme at a mid-size Norwegian insurer?+
A mid-size Norwegian insurer migrating a single core system — policy administration or claims management — with a personal lines book of 150,000 to 300,000 policies should budget in the range of NOK 18 million to NOK 55 million for a lift-and-shift or re-platform approach, and NOK 60 million to NOK 140 million for a cloud-native re-architecture. The wide ranges reflect integration complexity, data quality remediation requirements, and regulatory compliance work. Programmes that do not budget for integration dependency mapping and data quality assessment typically encounter unplanned costs of NOK 8 million to NOK 25 million. Specific cost estimates should be based on a detailed scoping exercise.[1][2]
This article provides general information only and does not constitute legal or regulatory advice. DORA, GDPR, and Finanstilsynet obligations for cloud-hosted insurance infrastructure require case-specific legal and compliance assessment. Insurers should consult qualified counsel for guidance specific to their jurisdiction and migration programme design.
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.
Cloud migration in insurance fails most often not from poor execution but from inadequate preparation: undiscovered integration dependencies, data quality problems, and unbudgeted regulatory compliance work. This post explains the three migration approaches, the integration mapping step most programmes skip, the DORA and Finanstilsynet obligations that apply, and what successful deployments show.
34 Integration Failures. 7 Months Delayed. NOK 8.4 Million Unbudgeted. All Preventable.
The migration programme launched in January with a 12-month timeline and a clear scope: lift-and-shift the policy administration system from the insurer's on-premise data centre to a major cloud infrastructure provider. The vendor had done this before. The internal team was experienced. The board had approved the budget. By July, the programme had paused.
The technical lead presents the situation to the steering committee at 09:30 on a Tuesday morning. Of the 87 integration points between the policy administration system and its downstream applications — the claims system, the finance platform, the distribution APIs, the customer portal, the document management system — 34 do not function correctly in the cloud environment. Some fail intermittently. Some fail consistently. Three produce data integrity errors that the team has not yet been able to reproduce in the test environment.
The remediation is unplanned. It was not in the original scope because nobody mapped the integration dependencies in detail before the migration began. The assumption was that a lift-and-shift would carry the integrations across unchanged. It did not. The revised timeline is 19 months from January, not 12. The additional cost is NOK 8.4 million, unbudgeted. The board does not ask about the cloud. It asks about the preparation.
Key Figures
| Figure | What it means |
|---|---|
| 72%[1] | Of insurance cloud migration programmes that overrun budget or timeline cite undiscovered integration complexity as the primary cause — not technology failure, vendor underperformance, or scope change. The integrations were present in the legacy environment. They were not mapped before migration began. |
| 38%[2] | Average reduction in infrastructure operating cost achieved by insurers that completed cloud migrations successfully, measured 24 months post-migration, driven by elastic scaling and consumption-based pricing replacing fixed data centre contracts. |
| 6 weeks[1] | Recommended minimum duration for integration dependency mapping before any cloud migration programme begins, based on documented deployment experience across mid-size insurer migrations. Programmes that skip or compress this step are 3.4 times more likely to encounter significant post-migration integration failures. |
| 61%[2] | Of European insurers in a 2024 survey had moved at least one core workload to cloud infrastructure, up from 34% in 2021. The acceleration reflects both cost pressure and the increasing cloud readiness of insurance-specific platform vendors. |
| NOK 8–25m[1] | Typical range of unplanned remediation costs incurred by mid-size insurers that begin cloud migrations without completing integration dependency mapping and data quality assessments. |
The Three Cloud Migration Approaches
Insurance cloud transformation does not mean the same thing to every insurer or every system. The approach chosen determines the complexity, cost, timeline, and ultimate value of the migration programme. Selecting the right approach before committing to a vendor or a timeline is the decision that shapes everything that follows.
| Approach | What it means | Timeline | Risk | Best when |
|---|---|---|---|---|
| Lift-and-shift | Move the existing system to cloud infrastructure without code changes | 4–10 months | High — integration issues surface post-migration | Speed is critical; system is stable; full rewrite is not viable |
| Re-platform | Move with targeted optimisations for the cloud environment; partial code changes | 10–18 months | Medium — optimisations introduce scope creep | System is broadly sound but has specific cloud compatibility issues |
| Cloud-native re-architecture | Rebuild the system for cloud-native operation: microservices, containers, event-driven | 24–42 months | Lower long-term; highest during transition | Legacy is at end of life; full capability transformation is the goal |
The lift-and-shift approach is the most commonly chosen and the most frequently problematic. Its appeal is speed and cost. Its failure mode is integration: systems that functioned correctly on-premise do not automatically function correctly in a cloud environment where integrations rely on network protocols, latency assumptions, or infrastructure configurations that differ between environments. The 34 integration point failures in the opening scene are a lift-and-shift failure, not a cloud infrastructure failure.
Integration Dependency Mapping: The Step Most Programmes Skip
Integration dependency mapping is the process of identifying every system that sends data to or receives data from the system being migrated, documenting how each integration works at the protocol and data format level, and assessing whether each integration will function correctly in the target cloud environment. It is the most important preparatory step in any cloud migration programme — and the one most consistently compressed or skipped.
The reason it gets skipped is that it is not glamorous work. It does not produce a visible deliverable until it reveals a problem. A six-week integration mapping exercise that uncovers 34 problematic integration points does not feel like a productive six weeks at the start of a programme. It is. Those six weeks prevent the NOK 8.4 million remediation cost and the seven-month programme delay.[1]
A proper integration dependency map covers: every system the migrating application connects to; the protocol and data format of each connection; the latency and throughput requirements; whether each connection relies on infrastructure features (IP addresses, network zones, certificate stores) that will change in the cloud environment; and the fallback behaviours of each downstream system if the connection is temporarily unavailable during migration. The output is a dependency register with a cloud-readiness assessment for each integration point. Any integration assessed as cloud-unready is a migration risk that must be addressed before the programme begins, not after.
Data migration risk
The data migration risk in a cloud migration programme is not primarily a technology risk. It is a data quality risk: incomplete records, inconsistent field values, undocumented business rules embedded in the data structure, and historical data that does not map cleanly to the schema expected by the cloud environment. A data quality assessment of the policy administration system should be conducted before any migration programme begins. Migrating incomplete or inaccurate data at speed does not produce a clean system faster. It produces an inaccurate system faster.
For Norwegian insurers, the GDPR as implemented through the EEA Agreement requires that personal data of Norwegian policyholders remains within the EEA unless an adequacy decision applies to the destination jurisdiction. A cloud migration that routes policy data through infrastructure outside the EEA without a valid transfer mechanism is a GDPR compliance failure, not just a technical oversight. Data residency requirements should be confirmed with the cloud provider before contract signature.
Regulatory Requirements for Cloud-Hosted Insurance Infrastructure
Cloud migration in insurance triggers regulatory obligations that are not present in an on-premise deployment. DORA, which came into force across the EU and EEA in January 2025, establishes specific requirements for cloud outsourcing by financial institutions. Finanstilsynet's guidance on outsourcing and third-party risk management applies to Norwegian insurer cloud deployments. The obligations are not optional and they are not addressed by the cloud provider's standard compliance certifications.
| Requirement | Framework | What it means for cloud migration |
|---|---|---|
| Outsourcing risk assessment | DORA Art. 28 / Finanstilsynet | Formal risk assessment required before contracting cloud provider; ongoing monitoring obligations apply throughout the contract period |
| Concentration risk | DORA Art. 29 / Finanstilsynet | Dependency on a single major cloud provider must be assessed; exit strategy required for each critical workload hosted |
| Data residency | GDPR / Finanstilsynet | Personal data of Norwegian/EU policyholders must remain within EEA unless an adequacy decision applies to the destination jurisdiction |
| Operational resilience testing | DORA Art. 24–25 | Cloud-hosted critical systems must be included in the TLPT (Threat-Led Penetration Testing) programme |
| Exit and portability | DORA Art. 30 | Contract must include exit provisions; data portability in standard format; transition assistance obligations on the provider |
The concentration risk requirement deserves specific attention for Norwegian insurers. DORA Article 29 requires financial institutions to assess and manage the risk of dependency on a single ICT third-party provider. For an insurer that migrates its policy administration, claims management, and finance systems to the same major cloud provider, the concentration risk is not theoretical. A cloud provider outage affecting all three systems simultaneously would constitute a significant operational resilience failure. The risk assessment must document this dependency and the mitigation measures in place. Specific regulatory interpretations for Norwegian cloud migration programmes should be verified with qualified Norwegian legal counsel.[3][4]
Measured Outcomes from Successful Deployments
Frequently Asked Questions
Our data is too sensitive to move to a public cloud environment.+
Major cloud providers operate financial services-grade infrastructure with security certifications — ISO 27001, SOC 2 Type II, PCI DSS — that typically exceed the security posture of on-premise data centres at mid-size insurers. The sensitivity of the data is a reason to evaluate the cloud provider's security controls rigorously, not a reason to remain on-premise by default. The relevant questions are: does the provider's data residency option keep policyholder data within the EEA; does the provider's security architecture meet Finanstilsynet's expectations; and does the contract meet DORA Article 30 exit and portability requirements? If yes to all three, the sensitivity concern is addressed.[3][4]
How long does integration dependency mapping take and can it run in parallel with migration planning?+
Integration dependency mapping takes a minimum of four to six weeks for a mid-size insurer with 50 to 90 integration points, and eight to twelve weeks for larger carriers with 100 or more connections. It can and should run in parallel with migration planning, vendor selection, and contract negotiation. It cannot run in parallel with migration execution: the output of the mapping exercise must inform the migration scope and approach before execution begins. Programmes that begin migration execution before completing dependency mapping are accepting the risk of discovering integration failures after go-live at a significantly higher remediation cost.[1]
What is the DORA concentration risk requirement and how does it apply to our cloud vendor selection?+
DORA Article 29 requires financial institutions to assess and manage the systemic risk of dependency on a single ICT third-party provider. For insurers, this means documenting the proportion of critical business functions that depend on a single cloud provider, assessing the impact of a prolonged outage, and implementing mitigation measures — which may include multi-cloud architecture, on-premise fallback for the most critical processes, or contractual resilience commitments from the provider. The concentration risk assessment must be maintained as a living document and reviewed when new workloads are added to the provider.[3]
How do we handle regulatory data retention requirements when migrating historical policy records?+
Insurance regulatory data retention requirements — typically 5 to 10 years for policy records and claims history depending on jurisdiction — apply to data in the cloud environment in the same way they apply on-premise. The migration plan must address: how historical records will be migrated (full migration versus archive-in-place for older records), how the retention schedule will be enforced in the cloud environment, and how data subject access requests and regulatory audit requests will be fulfilled from cloud-hosted records. Norwegian data retention requirements under forsikringsvirksomhetsloven and GDPR apply regardless of where the data is hosted.[4]
What should the exit provision in our cloud vendor contract specify?+
Under DORA Article 30, the exit provision must specify: the format in which all data will be exported on contract termination (structured, machine-readable formats in standard schemas); the minimum notice period for termination; the transition assistance the provider will give, including the duration and scope; the cost of exit, including data export costs; and the provider's obligations regarding data deletion after the exit period. Provisions that specify 'best efforts' or leave format and cost unspecified do not meet the DORA standard. The exit plan should be negotiated as part of the initial contract, before the insurer has accumulated dependency on the provider.[3]
What is the typical budget for a cloud migration programme at a mid-size Norwegian insurer?+
A mid-size Norwegian insurer migrating a single core system — policy administration or claims management — with a personal lines book of 150,000 to 300,000 policies should budget in the range of NOK 18 million to NOK 55 million for a lift-and-shift or re-platform approach, and NOK 60 million to NOK 140 million for a cloud-native re-architecture. The wide ranges reflect integration complexity, data quality remediation requirements, and regulatory compliance work. Programmes that do not budget for integration dependency mapping and data quality assessment typically encounter unplanned costs of NOK 8 million to NOK 25 million. Specific cost estimates should be based on a detailed scoping exercise.[1][2]
This article provides general information only and does not constitute legal or regulatory advice. DORA, GDPR, and Finanstilsynet obligations for cloud-hosted insurance infrastructure require case-specific legal and compliance assessment. Insurers should consult qualified counsel for guidance specific to their jurisdiction and migration programme design.
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.
Cloud migration in insurance: what carriers need to know before moving core systems