Ten steps to secure success with your Data Migration to

Guidewire PolicyCenter
For many carriers starting a new Policy Administration System implementation, the
data migration of their policy portfolio is the most risky and difficult part of the
project. Regardless of how well the application is configured to meet the functional
requirements of the organization, if the data migration is problematic then this can
easily cause operational and reporting issues, impact your customers and harm user
acceptance of the new application.

Most products, provide one or more ETL/API data migration approaches to import
your legacy data, so the challenge with migration is less of a technical one but more
around legacy data integrity, planning, process and execution. In this blog we tackle
data migrations for Guidewire PolicyCenter and list ten best practice suggestions
gleaned from successful Guidewire PolicyCenter migration projects that may help
make for a smoother PAS data migration in your own implementation.

1. Most importantly, keep it simple and do an ‘at renewal’ migration, this decouples
your new system from the legacy application and is the simplest and cheapest
option. Sure, there is the inconvenience and cost of your legacy application being
in production for another 14 months, but in most cases the costs of attempting a
‘big-bang’ migration outweigh the benefits. In the case of Guidewire
PolicyCenter the RenewalAPI, GX Models and Enhancements provide an easy way
to build out the entity graph and populate properties.

2. Put together the right team – The migration team will need quite a varied skill
set, probably more so than any of the other project teams. On the technology
side you will need legacy DB technical and application knowledge, an ETL person
to extract & cleanse into a landing zone or staging area, BAs knowledgeable in the
data models of both systems for mapping, a business process person to define the
end-to-end process, a data architect to manage the future state data model as well
as analytics and reporting implications during the transition period. For
PolicyCenter an integration specialist with Renewal API, XML, entity model and
product model skills will be required.

3. Embrace Agile – Two of the basics of Agile are collaboration and responding to
change, and no doubt you will find unexpected challenges, often around data
integrity and cleansing. Keep your product owner informed, groom your
backlog, re-prioritize and don’t get hung up on edge cases that involve a small
number of policies. Devise a manual work around for these, perhaps by creating
an underwriting issue on the converted policy in PolicyCenter, flagging it for
 manual review. Work closely with the PolicyCenter team to ensure as the
product model, entity model and rating evolve migration mapping rules are
adjusted accordingly. The general practice for Guidewire implementations is to
treat the migration as an Integration, but we have found benefit in the migration
team attending the PolicyCenter daily scrum, thereby knowing exactly what is
happening in PolicyCenter and calling out data migration implications.

4. At its heart data migration is a giant mapping effort, so you need a determined BA
with an eye for detail to manage data element mapping, code values mapping and
to agree transformation rules or default values with the underwriters and other
SMEs. Get the Policy team involved to assess the implications of the mappings,
it’s no good defaulting values that will generate excessive underwriter referrals
or adversely impact rating and generate unwanted premium increases. Start
profiling the legacy data in the project inception phase or Sprint 0 and
understand early how much cleansing is required, this will then feed into the
mapping process. Consider third party standardization tools to cleanse names
and addresses and to assist with deduplication. The best migration projects add
business value by massaging and cleaning the data during migration.

5. Consider the impact of migrated policies in your PolicyCenter inception

workshops and story cards, otherwise the final sprints will be impacted by
PolicyCenter rework to cater for incoming policies. Do you need special
typecodes such as ‘unknown’, only valid for migration policies? When specifying
validation, business rules or underwriting issues the story card should specify if
they apply to migrated policies. How will rating work on a migrated policy, do
we need special rating neutral values for migrated policies? If rating is changing
consider whether capping and cupping of premium is required. Always migrate
the expiring premium onto the new policy period for capping and cupping
purposes or to produce premium variation reports so unexpected premium
movements can be analyzed in the stabilization phase.

6. User signoff can be difficult and contentious – A good approach is for the
migration team to do the first-cut of data mappings, most of which are straight
forward. The remaining issues and a recommendation can then be presented at a
workshop to all stakeholders, which would include underwriting, customer
service, marketing, the digital team as well as reporting and analytics. A
consensus as to the best solution can then be reached based on the impact to each
area.

7. Focus on the migration business process as well as the technical architecture and
process. For the business process consider where renewal underwriting checks,
integrations or value-up logic will be done, in the legacy system prior to
 migration or in PolicyCenter post-migration? Your business users will be
operating on two systems during the transition and will need clarity on exactly
what is done where, and to clearly understand the process around double
handling late term policy changes that may need to be reapplied to the renewal
quote in PolicyCenter. Agree your migration reconciliation strategy with finance
and audit early and build that into the business process.

8. Get the development timing right – Don’t jump in start development too early, as
the product model and entity model will change and cause migration re-
work. There is plenty of data profiling, mapping and process work to do in the
early sprints. The trick is to too find the right balance: start late enough so the
product and entity model are stable, but still leave enough time for migration
development and stabilization.

9. Detailed logging and daily reports will be required, not just for the migration
itself but for post-migration errors in PolicyCenter, such as a renewal failing to
quote or a policy documents failing. Unexpected errors can be forgiven,
particularly where caused by inferior quality data in a complex transformation,
but what is unforgivable is not managing errors well. A clearly defined process
around migration error monitoring, data fix management/approval and retry will
make for smooth migration process and minimize fallout.

10. Testing should start early and the whole team should start using the migrated
entities as soon as they are fit for test. For example, once the Account migration
is done migrate large blocks of accounts with sensitive data obfuscated into all
environments & encourage the team (developers, BAs, QA) to create policies and
do their story testing on these migrated accounts. The migration team should be
responsible for ensuring entities are populated and the policy will quote and
produce a schedule. At that point SMEs in specific areas (rating, document
production, billing) commence testing on migrated policies. Don’t just roll the
clock forward enough to check delinquency, roll it forward all the way to the next
renewal, and observe the next renewal on the converted renewals.

Moving your portfolio to PolicyCenter needs to be carefully planned and executed,

but if done well can not only result in a smooth implementation but can add value in
terms of improved data quality, analytics and customer experience.