An AMS data migration tool moves a book of business from one agency management system into another: clients and contacts, policies and their terms, coverages and limits, carriers, producers, activity notes, attachments, claims, certificates and the accounting behind them. After an agency acquisition the move is the easy part. The hard part is deciding what each of the seller's values means in the buyer's system and which records are the same insured, because a wrong guess turns into a wrong renewal, a wrong carrier or a coverage nobody can find. Botminds' Agency Acquisition Data Migration is built around that hard part: six agents read, map, match and check the seller's whole book, each with a written limit, and a person decides every mapping, merge and exposure the agents cannot settle with confidence.
This guide is for the integration manager, agency IT lead or data analyst choosing how to move an acquired book. It sets out what any tool should be asked to do, what it should never do alone, and how to test one on your own export before you buy. The screens are from the solution, shown on a fictional sample acquisition: Calder & Pike, a buyer, converting Bramblewood Insurance Agency's 41-table export of 212,406 rows and 58,214 attachments.
What should an AMS data migration tool do, and what should it never do alone?
It should do the reading and comparing at volume, propose every translation with its evidence, and stop at the decisions that commit the agency. In the solution those decisions are written as limits on each agent, not as good intentions. The matrix below is the clearest way to judge any tool: list the jobs, then ask the vendor which of them the software will complete without a person.
Six jobs in an agency system migration, and the limit on each agent
| Agent | What it may do | What it may never do |
|---|---|---|
| Agency system reader | Read every table and attachment in the seller's export, profile each field, link each file to its client and policy | Change anything in the seller's system; every value cites its table and row |
| Field and code mapper | Propose a target for every field and code value, with a confidence and sample values checked against declarations pages | Approve a mapping below 95% confidence, or drop a field without a person deciding it is not carried |
| Client matcher | Standardise names, addresses, phones, emails and tax IDs; group records of the same insured within and across both books | Merge two different tax IDs, or merge anything without approval |
| Declarations reconciler | Compare each policy record with its declarations page: premium, limits, dates, named insured, forms | Change a premium or a limit; it reports the difference with the page |
| E&O exposure finder | Read notes, emails, certificates, notices and open claims for what the buyer inherits | Contact a client or a carrier; every exposure cites its document |
| Renewal and appointment checker | Match upcoming renewals to the buyer's carrier appointments and flag the gaps | Move a policy to a carrier code the buyer does not hold |
Notice what the right-hand column protects. Each limit stands in front of a decision that has an owner outside the migration team: the insured's legal identity, the premium the carrier charged, the client relationship, and the buyer's authority to write with a carrier. A tool that can cross those lines on its own is fast in a demonstration and expensive in the first renewal season.
What is an AMS data migration tool? Four kinds sold under one name
Four quite different things are sold or offered as AMS data migration: the target system vendor's conversion service, general data mapping and ETL software, manual re-keying, and agents with people reviewing. Most real migrations combine two of them, so the useful question is which one decides what each value means.
Four ways to move an agency system, and what each leaves to you
| Approach | Good at | Leaves to the buyer |
|---|---|---|
| Target system vendor's conversion | Loading into its own schema; knowing its own required fields and code lists | What the seller's codes meant, duplicates across both books, anything read from notes or documents |
| General mapping and ETL software | Repeatable transformations once the rules are written; volume | Writing every rule; it applies a mapping, it does not propose one with evidence |
| Re-keying by staff | Judgement on each record as it is typed | Consistency, time and the renewals that arrive while it happens |
| Agents with people reviewing | Proposing every mapping and match with evidence; reading notes and documents | Every decision below the confidence threshold, every merge, every exposure |
The target vendor's conversion is often the right way to load data, because nobody knows the destination schema better. What it cannot know is the seller's private conventions, and every agency system acquires them. In the sample export the seller used one status code, "R", for two different events; a carrier code, RDG2, for two different companies; and a line-of-business code, INMRC, for two different coverages. Those are not loading problems. They are questions about the seller's history, and the answers live in declarations pages, notes and the memory of the seller's staff.
What data moves in an AMS conversion?
Everything the buyer will need to service, renew, defend or account for the book moves, and some of it moves only as an archive. A practical inventory has ten groups: clients and contacts; policies and terms; coverages, limits and deductibles; carriers and their codes; producers, account managers and their codes; activity notes; attachments such as applications, declarations pages, emails and scans; claims; certificates issued; and receivables and commissions.
The history window is a decision, not a default. The sample integration carries seven years of policy terms and notes into the live system and sends older history to an archive copy. Whatever the window, the archive has to stay readable: Florida, for one, requires agents to keep records of the policies they transacted, including applications, change endorsements and documents the insured signed, for at least five years after each policy expires, in the office or in electronic or photographic form (Fla. Stat. §626.748). The record retention guide for acquired agencies sets out what to keep, archive and destroy.
How do you migrate data between agency management systems?
In seven steps, alternating between agents that propose and people who decide: read the export, map fields and codes, match clients, reconcile policies to their declarations pages, list inherited exposures and renewal gaps, test-load and tie out, then freeze the old system and load the final changes. The order matters, because each step's decisions feed the next one's evidence.
Moving an acquired agency's system: agents propose, people decide
Agent
Read the whole exportEvery table profiled, every attachment linked to its client and policy, damaged files named.
Never: write to the seller's system
Agent
Map fields and codesA target and a confidence for each field and code value, with a drafted rule for the doubtful ones.
Never: approve below the threshold
A person decides
Analyst decides the doubtful mappingsFrom the evidence and the proposed rule; "not carried" is a decision with a reason.
Agent
Match clients and check policiesDuplicate clusters within and across books; each policy against its declarations page; exposures and renewal gaps listed.
Never: merge or change a premium
A person decides
Merges, exposures and appointments ownedAnalyst approves merges; the E&O lead owns each exposure; licensing requests missing appointments.
Agent
Test-load and tie outLoad to a staging copy; count clients, policies, premium, claims and notes against the export.
A person decides
Integration manager signs the day-one loadEvery count tied and each open item cleared or accepted with its reason; then the old system goes read-only and the final changes load.
Two points in that sequence are where a migration can slip. The first is the gap between the export date and cutover: the seller's staff keep working, so the final load must carry the changes made since, which is why the old system goes read-only before the final delta. The second is the test load. A load that runs is not a load that is right; the tie-out is what proves it.
Can AI map agency system fields?
Yes, if it shows its evidence and knows when to stop. An agent can propose a target for each field and code value by reading sample values, comparing them with the documents they came from and scoring its confidence; it should approve on its own only above a threshold the buyer sets, and hand everything below to a person with a drafted rule.
The sample shows the shape of the result. Of the seller's 146 fields, the mapper drew 131 confident mappings, left 11 doubtful for a person and proposed 4 as not carried. Of 1,094 code values it mapped 1,062 confidently and left 32 doubtful. The doubtful ones are not the residue of a weak model; they are the places where the seller's data is genuinely ambiguous.
On the sample export, most mappings settle themselves and a few need a person
The most doubtful field was STATUS, at 61%. The seller had used "R" on 1,286 policies; 1,212 of them kept their policy number from the prior term, and 74 had a new number and a different prior carrier. The mapper proposed "Renewed when the policy number carries over, otherwise Rewritten", showed the counts behind it and waited. A person approved it, the rule applied to every record, and the doubtful count fell from 11 to 10.
A doubtful mapping arrives with its evidence and a proposed rule
How do you handle custom codes in an AMS migration?
Map every code value, not just every field, and anchor carrier codes to an identifier that exists outside both systems. Agency systems keep their own lists for lines of business, carriers, policy statuses, staff and transaction types, and acquisitions bring a second set of lists with different spellings for the same things. The mapping has to be done value by value, with the number of policies using each value, because a code used on three policies and a code used on a thousand deserve different amounts of attention.
For carriers, the anchor is the NAIC company code, which the NAIC describes as "a five-digit identifying number assigned by NAIC, assigned to all insurance companies filing financial data with NAIC" (NAIC glossary). Two carrier names that look alike can be two companies in one group with different appointments, which is exactly what the sample's RDG2 code was: Ridgeline Indemnity on 119 declarations pages and Ridgeline Mutual on 8. Mapping the code to a company name would have put eight policies with the wrong insurer.
Status codes deserve the same care for a different reason. In the sample, the seller's status "P" on 58 policies proposed to map to "Quoted, not bound". That is a servicing state, but it is also a list of promises the buyer may inherit, and the E&O exposure finder reads it as such. The data mapping template shows how to record each code translation with its count, evidence and approver.
Codes are mapped value by value, with the number of policies behind each
What should never be merged or changed automatically?
Four things: two client records with different tax IDs, a premium or limit the carrier charged, a policy's carrier code where the buyer holds no appointment, and anything a client or carrier would see. Each is a fixed rule in the solution, not a setting, because each one has legal or financial weight that a migration should not change.
Two tax IDs. A business with a different taxpayer identification number is, for most purposes, a different named insured, even at the same address with the same phone. Merging them can attach one insured's policies and claims to another. The matcher may propose them as related; it may not make them one.
Premiums and limits. When the system record and the declarations page disagree, the reconciler reports the difference with the page; a person decides which is right. In the sample, 142 policies disagreed with their pages, among them a commercial auto policy listing five vehicles where an endorsement on page 3 had added a sixth, premium already included.
Carrier codes the buyer does not hold. Under the NAIC's model producer licensing act a producer may not act as an insurer's agent without an appointment from that insurer (NAIC Model #218, §14). Moving a renewal onto a carrier the buyer is not appointed with is not a data fix; it is a placement decision for licensing and the account manager.
Anything client-facing. No agent contacts a client or carrier. Inherited clients also bring screening duties: the Treasury's sanctions office expects insurance brokers and agents to comply "throughout the lifecycle of their involvement" with a policy (OFAC insurance FAQs), and a migration is a natural point to screen the clients a buyer has just taken on.
How do you validate a data migration?
Count everything in the export again in the load, tie the money to the cent, and check a field-level sample against source documents. Counts alone hide offsetting errors; documents alone cover too few records. The two together are what a sign-off can rest on.
In the sample's third test load, the tie-out compared clients (3,412 records in the export, 3,198 after merging 214 records in 187 clusters), 4,206 active policies, $14,218,640 of written premium tied to the cent, $1,862,300 of annual commission, 63 open claims and 9,814 activity notes. Attachments tied at 58,204 of 58,214, with ten damaged scans named and the originals requested from the seller. Every open item went onto the sign-off with a reason.
The declarations check is the field-level half. A record and its declarations page are two versions of the same policy, and where they disagree the page is usually right because the carrier issued it. Policy Servicing's guide to a data migration reconciliation report goes deeper on what totals can hide.
Does the AMS vendor do the migration?
Often the target system's vendor will load the data, and sometimes it will map it too; what it may not have is the seller's context. Before relying on a vendor's conversion, ask who maps codes with two meanings, who finds duplicates across the two books, whether anyone reads notes and attachments, and what the vendor returns when a value does not fit.
Any vendor that holds the export takes on data security duties with it. The NAIC's Insurance Data Security Model Law makes a licensee require each service provider to protect, with administrative, technical and physical safeguards, the systems and nonpublic information it can reach or holds (NAIC Model #668, §4). A migration vendor holds the whole book, with names, addresses, tax IDs and claims, for weeks; contract terms, access logs and disposal of every extract after sign-off belong in the statement of work. States that adopted the model vary, and the model exempts licensees with fewer than ten employees from its security-programme section, so check the buyer's own state.
What to look for in an AMS data migration tool: eight questions for the demonstration
Ask to see each of these on a sample of your own seller's export, not on the vendor's demonstration data. A tool that cannot show them on real data will not do them on day one.
Eight questions to ask before you buy an AMS data migration tool
- Does it propose mappings, or only apply them?
Proposing with evidence is the work; applying a rule someone else wrote is the easy half.
- What does it do below its confidence threshold?
It should stop and draft a rule for a person, with the counts behind it.
- Does it map code values one by one?
With the number of policies on each value; carrier codes tied to the NAIC company code.
- Can it read attachments and notes?
Declarations pages settle disagreements; notes hold declined coverage and promises.
- How does it treat two tax IDs at one address?
Related, perhaps; one client, never without a person, and only with the same tax ID.
- What does it report when a record and its declarations page disagree?
The difference with the page cited, never a silent overwrite.
- What does the tie-out compare?
Clients, policies, premium to the cent, claims, notes and attachments, export against load.
- Can every change be traced and undone?
Who decided, when and why; merges reversible with a reason; original values kept.
Where the solution fits, and where it does not: it is built for an acquirer moving a bought agency's book into its own system, with a second set of codes, duplicate clients across books and inherited exposures to find. A same-vendor version upgrade with identical code lists needs little of it. It does not replace the buyer's agency management system or its loading routine, and it does not make licensing, coverage or client decisions; it puts each of them in front of the person who does. How the six agents work end to end is on the Agency Acquisition Data Migration page, and what the choice costs is priced in insurance data integration after an acquisition.
Questions people ask
What is the difference between an AMS conversion and a data migration?
People use the words interchangeably for agency systems. Where a difference is drawn, migration means moving the data and conversion means translating it so the new system reads each record the way the old one did. Policy Servicing's guide to data conversion vs data migration sets out the distinction for policy systems.
Can attachments and scanned documents be migrated?
Yes, and they should be linked to their client and policy rather than dumped in a folder. In the sample, 58,204 of 58,214 attachments loaded; ten scans would not open, were named on the sign-off and were requested again from the seller.
Should you clean the seller's data before or after the migration?
Before the day-one load, in a staging copy, never in the seller's live system. Cleaning after go-live means account managers work on duplicates and wrong codes during the first renewal season, which is the most expensive time to find them.
What does "not carried" mean in a data migration?
It means a source field is deliberately left out of the new system, usually because nothing in the buyer's system uses it. It should be a recorded decision by a person, and the data should still be kept in an archive for as long as retention rules require.
How long does an AMS data migration take?
It depends on the book and on how quickly the seller's export arrives. The solution's design target is six weeks from close to day one for a mid-sized agency, with two of those weeks kept for test loads, tie-out and sign-off.