Post-merger integration for insurance agencies: the workstreams and the data each one needs
Abe Harbid, 26 October 2026
Post-merger integration at an insurance brokerage is six workstreams running at once: people and producers, carriers and appointments, clients and service, systems, finance, and reporting. Every one of them depends on the acquired agency’s data, and most of them stall on the same few files. Alvarez and Marsal describe the shift in the sector plainly: consolidators that once bought brokers for scale now have to create value through what happens after the acquisition [1].
Why integration is a data problem first
A brokerage acquisition buys a book of business, the people who write and service it, and the carrier relationships that pay for it. Each of those lives in records: the agency management system, the carrier statements, the producer agreements, the appointment filings. The deal model assumed numbers drawn from those records. Integration is the work of making the records true inside the buyer’s own systems, and of keeping revenue flowing while that happens.
That is why the same failure shows up across workstreams. The carrier team cannot confirm appointments without a clean list of the policies by carrier. Finance cannot book commission revenue by agency until statements match the book. The producer team cannot set comp plans until it knows which policies belong to which producer. All three wait on the same export.
The six workstreams
| Workstream | What it settles | Data it needs from the acquired agency |
|---|---|---|
| People and producers | Roles, comp plans, book ownership, retention agreements | Producer roster with codes, current splits, the policies each producer is credited with |
| Carriers and appointments | Which carriers stay, which appointments move, which contracts change | Policies and premium by carrier, the agency’s carrier codes, direct bill and agency bill split |
| Clients and service | Who services which account, renewal calendar, client communication | Clients, contacts, policy dates, account managers |
| Systems | When and how the agency moves to the platform’s management system | The full export, in whatever layout the agency’s system produces |
| Finance | Commission revenue by agency, receivables, trust accounting | Carrier commission statements, expected commission by policy, open receivables |
| Reporting | When the agency appears in the platform’s numbers | All of the above, mapped to the platform’s standard |
The order that works
Run the data intake first, even when the system conversion is scheduled months out. The intake is the export, mapped and checked, and nothing more. It gives every other workstream the same list to work from, and it surfaces the problems that would otherwise appear one at a time in each team’s spreadsheet.
Then reconcile commissions, because cash shows whether the mapped book is right. A policy that appears in the export but never on a carrier statement is a question. A statement line for a policy the export does not hold is a bigger one. Our note on why statements stop matching lists the usual causes.
Producer comp and appointments follow, because both need the reconciled book. Last comes the system conversion itself, run by the platform’s conversion team or a vendor, with the mapping and the decisions already made.
What usually goes wrong
- Each team builds its own copy of the book. Carrier, finance and producer teams each pull the export and clean it differently. Three versions of the truth produce three different revenue numbers.
- Reporting waits for the conversion. The agency stays outside the platform’s dashboard until it is fully converted, which can be well over a year [2]. In the meantime nobody can tell whether it is growing.
- Decisions are not kept. Someone decides that a carrier code maps to a carrier, or that an unassigned policy belongs to a producer. When the export is pulled again, the decision is lost and made again.
- Every deal starts from zero. A platform buying ten agencies a year rebuilds the same mapping for every agency on the same system.
How a platform can keep integration repeatable
Treat the intake as a product the platform owns. A standard layout for the platform’s book, a mapping for each source system that is kept and reused, a fixed set of checks, an error report a person works through in order, and a decision log that survives a re-run. Our page on running integration as a program covers the operating side: who owns the intake, how the deal team hands over, and what each acquisition’s scorecard holds.
The acquisition-onboarding engine is that intake. It takes the acquired agency’s export, carrier statements and producer data, maps them into the platform’s layout, flags duplicates, missing fields, unmatched producers and unknown carrier codes, reconciles the statements against the book and puts the agency on one dashboard next to the rest. The platform’s own team keeps every decision and does the final import.
Questions
What is post-merger integration at an insurance agency?
It is the work after closing that makes the acquired agency part of the buyer: producers on the buyer’s comp plans, appointments and carrier contracts sorted out, clients serviced the buyer’s way, the book in the buyer’s systems and the revenue in the buyer’s reporting.
Which workstream should start first?
The data intake: the acquired agency’s export mapped to the platform’s standard and checked. Every other workstream needs that list, and starting with it stops each team from cleaning its own copy.
Does the agency have to be converted to the platform’s system before it appears in reporting?
No. A mapped and reconciled export can put the agency in the platform’s numbers within the first quarter, while the conversion follows on its own schedule. Alvarez and Marsal make the same distinction between consolidated reporting and full system integration [2].
Who usually owns integration at a brokerage platform?
Larger platforms have a chief integration officer or a VP of M&A integration with a small team. Others split it between operations and finance. Either way, someone should own the intake and the decision log, because every workstream depends on them.
How is this different from a data conversion?
A conversion moves the book into one management system. Integration is wider: it covers people, carriers, finance and reporting too. Agency data conversion covers the conversion part.
See how the engine handles intake on the insurance platforms page, or start with a two-week diagnostic on one recent acquisition.
Sources
- Alvarez and Marsal, "Consolidation in the global insurance brokerage market" (2023 report, accessed 26 October 2026). alvarezandmarsal.com
- Alvarez and Marsal, "Better data, better exits: the new playbook for wealth and insurance platform roll-ups" (accessed 26 October 2026). alvarezandmarsal.com