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.

To plan strategies, incorporate best practices and successfully execute your Data Migration, feel free to reach out to the Cynosure Data Management Practice. To learn more contact Tom Mullens – Cynosure’s Director of Data Management at

+ posts
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)


Posted by Tom Mullens

Leave a reply

Your email address will not be published. Required fields are marked *