The deal is done, now the data
You have bought a smaller brokerage, or a book of business from a retiring broker. The clients are yours from a date. Their records are in the seller's broking system, which may be a different platform from yours, an old version of the same one, or a set of spreadsheets and folders. Renewals start falling due within weeks.
The obvious approach is to export and import. The export turns out to have its own trade codes, insurer names spelled three ways, clients duplicated across personal and business records, and documents in a separate archive. Meanwhile handlers work renewals in the old system with a login that is due to expire.
Why book migrations go wrong
Every broking system models clients, policies and transactions a little differently. Trade descriptions, insurer and product codes, handler names and statuses need mapping. Some clients exist in your system already, because they also bought something from you. And the seller's data was kept for the seller's purposes, so fields you rely on may simply be empty.
- Codes for trades, insurers, products and statuses differ between systems.
- Duplicates within the seller's data and against your own clients.
- Documents and notes held separately from the policy records.
- Renewals falling due during the migration window.
- No reconciliation, so nobody can say every policy arrived.
What a messy migration costs
Renewals missed during the move are clients lost, which goes straight to the value of the acquisition. Handlers work in two systems for longer than planned. Data problems surface for years afterwards, at every renewal, in every report. And any file review of acquired business starts with finding documents that did not come across.
A staged migration, checked against the source
- We extract everything available from the seller's system: clients, policies, transactions, notes and documents, using exports, database access or the system's API.
- A mapping is built for every code the seller used, including trades, insurers, products, handlers and statuses, and reviewed with your team.
- Clients are matched against each other and against your existing clients, and proposed merges are listed for a person to approve.
- Missing fields that your system requires are listed per record, so they can be completed before load or flagged for the handler at renewal.
- Records are loaded in stages ordered by renewal date, so the earliest renewals are in your system first.
- After each stage, counts and values are reconciled against the source, and a sample of records is checked in full by your staff.
- Documents and notes are attached to the right client and policy, and an index is kept of anything that could not be matched.
- The seller's data is archived in a readable form in case questions arise later.
Reconciliation at each stage
| Check | What is compared |
|---|---|
| Client counts | Source, extract and your system |
| Live policies | Count and premium by insurer |
| Renewal dates | Every live policy has one, in the right month |
| Documents | Each policy's documents attached and opening |
| Merges | Every merge approved by a person |
Any difference is explained and recorded before the next stage begins.
A book that is truly yours
Handlers work acquired clients in your system with the same fields, documents and history as any other client. Renewals do not fall through a gap between systems. And if anyone asks later whether every policy came across, the reconciliation answers it.
Is this your next acquisition?
- You are buying a book held in a different system or in spreadsheets.
- Renewals fall due within weeks of completion.
- Some acquired clients already exist in your system.
- Nobody has checked that the seller's documents will come across.