In Part One of this blog post series, I discussed some data migration approaches for Guidewire ClaimCenter®. In this second part, let’s examine some data migration approaches for our insurance policy administration system: Guidewire PolicyCenter®.
Manual Approach: This option is typically viable only for insurers with lower policy volume insurers. A manual migration consists of keying inforce policies into the new system (in this case, PolicyCenter) and retaining all historical policies on the legacy system. While relatively inexpensive, there is a risk of keying errors and effort needed to manually balance the entry, plus both the legacy and new systems will run concurrently until the need to view old policies or disconnection of all legacy-connected systems is complete. Also, prior to retirement, the data in the legacy system will need to be saved into a data repository for safekeeping.
“Big-Bang”: This option is typically for insurers who need to retire their legacy system as fast as possible and roll PolicyCenter out in one phase. This has the potential for greater risk, as all the data must be cleansed and operationalized for the new system (both historical terms and inforce terms), which may include past product definitions, rates, rules, forms, etc. Depending on the quality of the legacy data, there may be additional effort to pass the data through more iterations than originally anticipated, resulting in project delay and additional cost. For customers with very large volumes of historical data, this approach could result in performance degradation in the new system with very large volumes.
On Renewal: This approach would retrieve the policy data from the legacy system for those policies coming up for renewal that day and store them in a predefined XML-formatted file for the PolicyCenter renewal accelerator, provided by Guidewire. The accelerator then takes the renewing policies, and uses the PolicyCenter APIs to instruct PolicyCenter to add those policies to the defined renewal workflows. This results in relatively low risk to the project, but the trade-off is data in multiple systems (e.g., endorsements of inforce policies - until runoff, remain in the legacy systems and all other entries are in PolicyCenter). This also means the history will remain on the legacy system, delaying its retirement typically up to one year.
Guidewire DataHub™ – On Renewal: Historical data can be transferred from the legacy system to DataHub in two phases. In the first phase, only the renewing policies are stored in DataHub (which uses a DataHub accelerator, provided by Guidewire, to deliver data in XML format), at which point the renewal accelerator would load into PolicyCenter (just as in the On-Renewal approach). This reduces risk to the PolicyCenter implementation by limiting the data to the renewing term and taking historical data conversion off the critical path of the project. The second phase would then take all the historical data into DataHub for safekeeping to retire the legacy system. Problematic issues such as handling out-of-sequence endorsements from legacy systems can then be tackled outside the critical PolicyCenter implementation. Data residing in DataHub can also be used for other purposes, such as downstream integrations and reporting. This option reduces the retirement risk as it retains the original source values, which can be used by other systems that remain, with less code changes. One option is to do both the historical and renewals in one phase, but this carries potentially more risk.
DataHub – Inforce: This option is like the DataHub – On Renewal option, but feeds all inforce terms in one pass, and then renewals each day. This enables entry into one system. Typically, as with DataHub – On Renewal, the history would be a second phase to help de-risk the PolicyCenter implementation, but need not be if there is pressure to disconnect the legacy systems as soon as possible. This option has the advantages of “Big Bang” with less risk, and the same retirement risk reduction as DataHub – On Renewal. One option is to do the history and inforce in one phase, but this carries potentially more risk, as the renewals would still happen daily.
In the last part of this blog series, I will examine data migration approaches for Guidewire BillingCenter®.