Migrating from another AMS without losing the messy 5%

Most agency management system migrations do not fail at the export. They fail about six weeks later, when someone needs a certificate for a policy whose holder record never made it across.

The pattern is consistent enough to be predictable. The vendor demo uses a clean sample book. The real export is not clean: it has three spellings of the same carrier, dates in two formats, policies whose producer left the agency in 2023, and a folder of PDFs nobody has opened since they were scanned. The import runs, reports success, and the parts it could not understand are quietly dropped or dumped into a generic bucket.

Nothing looks wrong on day one. The dashboard is full, the counts are roughly right, and the agency starts working. The failure surfaces one record at a time over the following months, and by then going back is not an option — the old system has been cancelled and three months of new work lives in the new one.

An AMS export is not a database. It is a snapshot of how one specific system decided to model an agency, flattened into rows.

That means three things arrive together, and they need different handling:

• Structured records — clients, policies, dates, premiums. These map reasonably well, though field names never match exactly.
• Semi-structured artifacts — ACORD forms, certificates, endorsements. They contain the same facts as the structured records, sometimes contradicting them.
• Unstructured residue — email threads, scanned letters, loose notes, a spreadsheet somebody kept on the side because the AMS could not do what they needed.

That third category is where the agency's actual institutional memory lives, and it is the category most migrations ignore entirely. If your new system only ingests the first category, you have not migrated the agency. You have migrated a report about the agency.

Between an export and a usable book there is real work, and it is worth knowing what it is so you can ask whether your vendor does it.

The two stages at the ends are decisions, not processing: what to bring, and whether to accept the result. The four in the middle are the ones that should not require a human. If a migration plan expects your staff to hand-map columns or retype dates, that plan has moved the work rather than doing it — and it is the reason migrations stall at 80% and stay there.

The 5% of a book that will not map cleanly is not noise to be discarded. It is disproportionately the part that matters.

There is a reason for that. Records go irregular when something unusual happened: a mid-term endorsement, a policy rewritten with a different carrier, a client who became two entities after a sale, a commission that was split. Clean records are clean because nothing happened to them. The irregular ones are the accounts with history, and history is correlated with size.

So a migration that silently drops what it cannot parse is not losing a random 5%. It is losing a biased sample weighted toward your most complicated and often most valuable accounts. This is why "the import reported success" is not the same as "the migration worked", and why a vendor that shows you a list of unresolved conflicts is giving you more than one that shows you a green checkmark.

The correct behaviour is boring: surface the gap, name the conflict, and make a person decide. It looks worse in a demo and is the only version that survives contact with a real book.

Five questions that separate a migration plan from a marketing claim. None of them require you to be technical.

• What happens to records you cannot match? If the answer is not "we show them to you", they are being dropped.
• Who normalizes dates, names and carrier codes? If the answer involves your staff and a spreadsheet, budget for it in weeks.
• Do documents keep their relationship to a policy? A migrated folder of PDFs is storage. A document attached to the policy it belongs to is a book.
• Can I see the migration before it becomes my live system? If the first time you see the result is also the first day you depend on it, you have no way back.
• What comes across by API and what by CSV? A direct connection preserves structure that an export flattens. It is worth knowing which one you are getting.

Agency Nexus connects to NowCerts through its API, and takes Applied Epic, AMS360, HawkSoft, spreadsheets and any other CSV export by field mapping.

After the upload, the four automatic stages above run: artifacts are identified by type, dates and names and carrier codes are normalized to one shape, documents are matched to their policy and policies to their client, and gaps and conflicts are surfaced rather than dropped. Nobody hand-maps a column.

The honest limitation is that no system can invent a fact that is not in your export. If the old AMS never recorded which holder a certificate went to, that link cannot be reconstructed — it can only be flagged as missing so someone can fill it in. A vendor telling you otherwise is describing a guess.

More detail on the mechanics is on the how it works page, and the specific migration questions agencies ask are answered in the FAQ.