Yazh (Yaal), our Integration Gateway, takes each renewing policy from your legacy system and delivers it to PolicyCenter with its current term and renewal term, so policies move one renewal at a time instead of in one cutover.
The Problem
Converting at Renewal Leaves Policies Split Across Two Systems
Many carriers convert policies as they renew, so legacy data reaches PolicyCenter in daily runs. Each run depends on legacy data matching the format PolicyCenter expects.
Legacy Data Doesn’t Match the Renewal Format
Guidewire’s renewal approach exports daily renewals into a predefined XML format for PolicyCenter. Legacy coverage, rating, and terms require field mapping before loading, while renewal dates remain unchanged.
The Legacy System Stays Open
Under this approach, endorsements on in-force policies stay in the legacy system until those policies run off. Guidewire notes that this delays legacy retirement, typically by up to one year. Until then the carrier pays to run both systems and servicing teams work in two places.
Every Upgrade Reopens the Build
Each connector a sender writes depends on PolicyCenter’s APIs and on the carrier’s own endpoints. When Guidewire or the carrier upgrades, the sender reworks and retests the connector. With a separate connector for each transaction, one upgrade means several rounds of rework.
The Solution
How does InsOps Help?
How Yazh (Yaal) Moves Submissions Into PolicyCenter
Bring Your Legacy Data
Send policy data in the format your legacy system already produces.
LiLa-Suggested Mapping
LiLa maps each source field to PolicyCenter and lists the fields it could not match.
Review Every Mapping
A person edits, adds or removes mapped fields before the mapping goes live.
Active Policies Only
Conversion covers policies in force, one renewal at a time.
Current and Renewal Term Together
PolicyCenter receives the in-force term and the renewal term in one delivery.
Logged and Monitored
Every request is authenticated, validated and recorded, with audit entries on the dashboard.
FAQ