While insurers understand that data is key in the age of digital transformation, they still face several challenges along the road to data modernization. A modern data platform is the first and most necessary step toward data modernization.
As insurers and brokers upgrade systems, acquire and sell books of business or consolidate data sources they must ensure the data is transferred seamlessly without any inconvenience to the customers or the business users of that data. It's vital that you retain its completeness as a business asset and its integrity for compliance.
Without detailed knowledge of the different data structures and business rules of both the source and target system's data migrations can often over-run or fail. With limited time and tools in-house teams and software vendors generally only migrate the minimum of information. This can result in a reliance on information from legacy systems, spreadsheets or paper files. This often leads to companies retaining multiple legacy systems which can be costly, difficult to support and making reporting across disparate data sources unwieldy with no single version of the truth.
Legacy System Data Migration Strategy to New Product
The right data migration strategy depends on a number of technical and organizational factors unique to each project. When deciding which data to migrate, how, and when, carriers must weigh the trade-offs between cost, complexity, and risk versus the business benefit of doing a more complete and immediate data migration. The approach often differs for claims, policy, and billing migrations because the nature of the systems and the needs of the business are unique to each application.
Before looking at the typical migration strategies for each commercial insurance product, it's useful to review the most important considerations when choosing a strategy:
Risk mitigation - Customers commonly choose to deploy new systems in waves across certain lines of business, regions, or organizational entities. This reduces the risk that a production problem will significantly disrupt operations. A phased rollout gives the organization an opportunity to resolve a contained number of issues before the entire enterprise is dependent on it. It also reduces the strain on training, change management, and IT support teams.
Segmentation of data - If using a wave deployment approach, carriers often use logical boundaries in the organization to migrate certain data immediately while leaving other data on the prior system. It is critical to identify clear boundaries so that there is no data dependency between the two systems and to minimize dual entry in two systems during the transition phase.
Migration coding cost and complexity - Different approaches can minimize the cost to develop data migration code. Customer may manage scope and costs by choosing to migrate only the most important data, migrating less history, doing some data migration manually, completing "in process" activities in the old system rather than migrating them to the new system, etc. While a more comprehensive migration approach increases cost and risk, it also may increase end user satisfaction and convenience.
Historical data - In order to retire the prior system, carriers must decide what to do with historical data. How much data must be migrated to the new system? Is the cost to migrate more data worth the additional investment? For example, more historical data also means more time to cleanse and map older data, more time to test and validate all the data, and more risk of performance impacts. Can reporting needs be met using a less expensive approach, such as migrating older data to imaged archives or a data warehouse?
Retirement deadlines - Another important consideration in the data migration strategy is the expense of maintaining the prior system for an extended period. If customers will incur significant out-of-support or end-of-contract expenses for the legacy system infrastructure, they may choose a more aggressive or more comprehensive migration strategy to meet these timelines and reduce unnecessary dual system costs.
The Path Forward: Modern Data Strategies by Product for seamless Migration
PolicyCenter Migration Approach
Historically, most successful policy system migration projects have taken a "migration-on-renewal" approach. Using this approach, the carrier turns on the new system and new business is processed in the system immediately. As policies come up for renewal in the old system, they are migrated into PolicyCenter as new policies.
Over the course of a full policy period (typically one year), all policies are migrated off the old system and onto the new system. This approach is favored over an "in-force migration" approach, where all policies are migrated "big bang" in the middle of their terms, for a number of reasons:
Data complexity
Clear data segmentation
Clear phase-in strategy
Of course, the migration-on-renewal approach also has some disadvantages:
Extended transition period
No history
BillingCenter Migration Approach
On billing projects, there are two common data migration approaches - either cutover the entire billing system at once or bring the new billing system up in parallel with migration-on-renewal to a new policy system. If the old billing system is being retired while choosing to migrate to BillingCenter in one large cutover, the first case, an old billing system is being retired and the new billing system will take over for it starting on a cut-over date.
In cases where the billing system is being replaced while leaving the existing policy system(s) in place, this is the most likely choice. Unlike PolicyCenter and ClaimCenter, there is little reason to implement and roll-out BillingCenter line-by-line, so a data migration to the new system for all lines at once often makes sense.
However, when BillingCenter is being implemented as part of a policy system replacement project, the choice is less obvious. Instead of doing a full cutover, it is often easier to migrate the ownership of policy billing into BillingCenter as the ownership of the policies themselves is migrated into PolicyCenter. In this way, the old policy system continues to be integrated only with the old billing system, and no data migration is required beyond the effort to migrate the policies into PolicyCenter on renewal.
The most important advantage of the full cutover approach is that it allows a single bill to be sent to the customer and a single commission statement to be sent to the agent. If the billing for all policies is not migrated at the same time, account-level direct billing or agency billing would produce separate bills for the policies being managed in the prior system versus those managed in the new system.
ClaimCenter Migration Approach
ClaimCenter implementation projects often deploy in waves across certain lines of business, regional locales, or organizational teams. For example, customers may choose a migration approach that allows most end users to work solely in the new ClaimCenter system but requires a small subset of users who support claims across different lines of business or office to work on two systems for a short time while the legacy system is gradually phased out.
To achieve this phased rollout plan, carriers often want to migrate all open claims owned by an office or set of users within a tight timeframe (e.g. a single weekend). A direct-to-database approach can most efficiently process large volumes of claims data quickly. Since claim data is typically far less complex than policy data, it is also more reasonable to migrate directly to the database.
Carriers may also want to migrate several years of previously closed claims, both to preserve history when shutting down the prior system and to allow these claims to be reopened (e.g. to process a supplementary payment). This can be done either as part of the initial data migration or after go-live. Carriers frequently prefer the latter approach to reduce the volume of data to cleanse, validate, and migrate during the short cutover window, thereby reducing risk.
As an alternative to a large bulk migration of open claims, carriers with predominantly short-tailed claims may choose to run off most claims in the prior system. This is particularly beneficial for carriers with a large percentage of open claims that will close within a short timeframe. The few claims that remain open after the run-off period can be migrated manually, and then the legacy system can be shut down. This approach greatly reduces or eliminates the expense of cleansing data and developing migration code.
