A new system chosen, a live book to move
You have outgrown your first policy administration system, or your new product needs something it cannot do. A new system has been selected. Now the book has to move: every in-force policy, with its history, instalment plan, documents, endorsements, open claims links, commission terms and renewal date. Customers keep paying, claiming and changing their policies throughout.
The vendor's migration tool imports policies from a spreadsheet. It does not know about your workaround spreadsheets, your partner-specific commission, or the policies that were adjusted three times last year.
Where migrations go wrong
Most records move cleanly. The trouble is in a minority that carries most of the risk.
- Policies mid-term with adjustments, where premium and cover have changed since inception.
- Instalment plans with payments due, part-paid or failed.
- Policies with open claims, where the claims system references the old policy record.
- Data held in workaround spreadsheets rather than the old system.
- Documents and wordings that must stay as issued, even if the new system would generate them differently.
- Renewal dates close to cutover.
The cost of a rough cutover
Wrong premiums, duplicated instalments or missing cover after migration affect customers directly, and they are the kind of error that reaches your capacity provider. Renewals issued wrongly from the new system damage retention. Claims handlers cannot find policies. Bordereaux built from the new system do not match the old. Cleaning up afterwards takes months.
Any obligations about how customers are treated during a system change are for your team and advisers. We handle the engineering and data.
A staged migration with checks
What we build moves the book in stages, with each stage checked against the old system.
- We map every data item in the old system and every workaround source, and agree how each maps to the new system, including what does not map.
- We choose a migration approach per group: move now, move at renewal, or run off in the old system. Moving at renewal often avoids migrating mid-term adjustments at all.
- Migration scripts extract, transform and load each group through the new system's API or import, with every record logged.
- After each load, checks compare old and new for every migrated policy: premium, cover, dates, instalments, documents.
- Instalment plans are moved with the payment provider's mandates or tokens re-linked, so collections continue without customer action where possible.
- Claims references are updated so handlers find policies in the new system.
- The old system is kept readable, or its data archived in a searchable form, for as long as you need it.
| Policy group | Typical approach | Main check |
|---|---|---|
| New business after cutover | Written in new system | End to end testing |
| In force, no changes | Migrate, or move at renewal | Premium, cover and dates match |
| In force with adjustments | Move at renewal where possible | Premium history preserved |
| On instalments | Migrate with payment links | Next collection correct |
| With open claims | Migrate and update claims links | Handler can find policy |
A cutover you can check
Each stage ends with a check report showing every policy compared and any difference explained. Groups move when their checks are clean. Customers see nothing change except, perhaps, a new document style at renewal. Finance can reconcile bordereaux across the two systems during the transition.
The mapping and checks built for the migration also leave you with a clear description of your book and your data, which makes the new system easier to run and the next change easier to plan.
Is this where you are?
- You have chosen, or are choosing, a new policy administration system.
- The vendor's import tool is the migration plan.
- Some policy data lives in spreadsheets outside the old system.
- Nobody has decided how mid-term policies will move.
- Instalment plans and open claims have not been thought through.