Hosting core business operations in the cloud has arguably become one of the most pivotal drivers behind the digital transformation of commercial lines over the past five years. This agile, flexible, and low-maintenance IT operational model is perfectly aligned with insurers’ digital aspirations. Although approximately 70 percent insurers dabbled in cloud deployments, there is no silver bullet to ensure a successful migration. Every insurance carrier has business goals, staffing, applications, and processes that uniquely define their cloud deployments. However, there are certain cloud migration components that every insurer must embrace to best ensure success on this journey.
Assessing your environment
An insurer's on-premise environment is not simply lifted and shifted to the cloud. Instead, the insurer and Software as a Service (SaaS) provider need to identify and evaluate connected applications and related end-to-end functionality prior to a migration. One of the initial steps is to clearly define the requirements of the application migration, including the non-functional requirements. While a system’s functional requirements typically describe the business functions of an application, its non-functional requirements (NFRs) can be thought of as the business requirements that govern the operation of the system. For example, a quoting application might be designed to run 24/7 or only during business hours. Ensuring that the application NFRs are validated as part of the migration is critical to delivering consistent post-migration system performance and a consistent end user experience.
Early in the migration project, insurers must speak with their SaaS provider about their critical disaster recovery service level objectives. These will include the recovery time objective (RTO) and recovery point objective (RPO), which define the maximum length of time a system can be unavailable during a disaster and the maximum amount of expected data loss following a disaster. For example, insurers may have an application required to run eight hours a day, five days a week, but can only afford to lose a maximum of five minutes of data (the RPO for this application) in the event of a disaster. Defining these parameters is a critical task that must be conducted with the business leaders to ensure that expectations are appropriately set and that the required operational procedures are put in place to conduct business during and after a disaster.
Insurers must also clarify the roles and responsibilities for managing their applications post-migration. They will need to determine which operational responsibilities they will continue to own (e.g. user provisioning and role assignment), and which will become the responsibility of the SaaS provider (e.g. system upgrades and performance tuning). Also, the tools required to manage application content such as documents, rates, and rules need to be identified and configured, and users must be trained to assume these new roles or processes for carrying out existing tasks. Should these considerations not be addressed during the migration, insurers are more likely to experience easily avoidable issues in production.
It isn’t just production environments that must be contemplated during the migration project, but also the test and configuration environments. Among the most desirable characteristics of the cloud are its flexibility and scalability, which enable insurers to meet their growth objectives as they enhance existing and roll out new products. This requires the regular testing of security, performance, and third-party dependencies of modern applications running across both production and non-production environments.
Software & Content Updates
In addition to addressing environment-related aspects of cloud migrations, insurers must also define the application lifecycle management (ALM) rules and the related content that populates their systems and drives their business processes. Core system upgrades are executed very differently once migrated into a cloud-hosted environment. Oftentimes, teams that historically managed on-premise core systems will no longer play the same role within a cloud-based environment. Insurers and SaaS providers must decide how they will work together to maintain the core application and its related upstream and downstream systems.
Third-Party Applications and Data Sources
Along with the core system, many insurers have third-party applications which must also be migrated from on-premise to the cloud, in order to advance their digital transformation objectives. Such third-party systems and data sources commonly include address and currency lookups, compliance scanning, document management and reservation services, and payment gateways. The migration to the cloud is also a natural inflexion point to re-evaluate existing data sources and third-party interfaces, as well as to evaluate new ones.
Insurers that write admitted lines and file rates and forms with state regulators have to determine how their bureau content update models will function in a cloud-based environment. A cadence of content updates, testing, and production environment uploads must be planned in accordance with the regular stream of published changes from bureaus such as ISO, AIIS, and NCCI.
Resources
Since the cloud frees insurers from the burden of managing and upgrading on-premise systems and their related infrastructure, it changes the way an organization can allocate resources and subsequently approach managing day-to-day operations. Areas such as security, compliance, application and infrastructure management, on-call support, and audit will all be affected by migrating core systems to the cloud. Insurers should re-evaluate their current support and staffing models in these areas as well as the associated skill sets required for each one in a cloud-based environment. The migration to the cloud enables insurers to leverage partners in non-core business areas and to refocus existing staff on their core competencies.
Service Level Agreements (SLAs)
Developing the SLA is the culmination of all the previous cloud migration considerations including identifying disaster recovery parameters, business expectations, and non-functional requirements, ensuring that insurers receive the services they require within the SaaS model. The SLA is the contractual agreement between a SaaS provider and the insurer that specifies the level of service to be delivered. Should the SaaS provider fail to meet the minimum requirements, the SLA should also include a credit accumulation model tied to SaaS fees that serves to refund the insurer in the event of an outage.
A pivotal component of the SaaS SLA is the type of monitoring and reporting used to demonstrate that the SaaS provider is adhering to the agreement. There should be a set standard for reports and, at minimum, quarterly SLA reporting which outlines downtime, maintenance, releases, and any credits accumulated during the period. Insurers should come to the table during the cloud migration contracting process with specific questions related to the SLA to ensure it ultimately meets business needs once the migration is complete.
Deploying core systems in the cloud is the gateway to digital transformation, enabling insurance companies to quickly adapt as organizational needs and priorities change. Cloud migrations can be easily derailed if critical stakeholders don’t address each of these key pillars and outline strict accountability from start to finish. Establishing clear, objective, and measurable means of evaluating the cloud migration is key to ensuring a successful migration and meeting or exceeding stakeholder expectations.
