How to Switch Your AMS Without Losing Your Book

Ask an agency principal why they’re still on a system they complain about weekly and you get some version of the same answer: moving the book is too risky.

It is a reasonable fear built on a real risk, and it is also the most effective retention feature the incumbent AMS vendors have. Nobody markets it. Nobody has to. The fear does the work.

But a migration is a known process with known failure points. Here is what actually happens, what actually breaks, and how to prove afterward that nothing was lost.

Before you touch anything: read your contract

Do this first, before you demo anything, because it determines your timeline more than any technical consideration.

• Term and auto-renewal. Multi-year terms with automatic renewal are standard. Find your renewal date.
• Notice window. Thirty, sixty, or ninety days before renewal is typical. Miss it by a day and you have bought another year.
• Export rights. What are you contractually entitled to receive, in what format, and is there a fee?
• Termination fees and any remaining implementation cost being amortized.

Then, while your account is still in perfectly good standing and nobody is annoyed with you, pull a complete export and keep it.Do this even if you’re only exploring. An export you already have is leverage; an export you have to request after giving notice is a negotiation.

Take inventory of what you actually have

Most agencies underestimate their data by about half, because a lot of it isn’t in the AMS. Before you plan a migration, list where each of these lives:

The three rows to fight for are notes, attachments, and prior-term history. Those are your institutional memory. A migration that moves clean customer and policy tables while losing a decade of notes has technically succeeded and practically gutted you.

Clean before you move, not after

A migration is an X-ray of your data hygiene. Every duplicate customer, every policy with a blank effective date, every carrier spelled four different ways — it all shows up as an exception report, and it is enormously easier to fix in the export than after it has been imported and built on.

Spend a day on the obvious wins:

• Deduplicate customers by name plus address or phone.
• Normalize carrier names so “Progressive,” “PROGRESSIVE,” and “Prog.” are one carrier.
• Decide what to do with dead records — policies cancelled six years ago that nobody will ever look at. Archive rather than migrate.
• Flag policies with no coverage detail. These need to be rebuilt from download or carrier portals regardless of which system you’re in.

Stage, review, then commit

The single most important structural property of a good migration is that nothing touches your live book until you approve it. The sequence should be:

1. Import into a staging area. The new system reads your files, maps the columns, and holds everything without writing to the live book.
2. Read the report. Rows found versus rows filed. Policies automatically linked to customers versus orphaned. Every exception listed individually, not summarized as a percentage.
3. Resolve exceptions.Fix at the source and re-import where the problem is in your data; resolve in-app where it’s a mapping question.
4. Commit — with an undo. Ask explicitly whether a committed migration can be rolled back, and for how long. Ours keeps a one-click rollback for 30 days; the mechanics are on the migration guide.

If a vendor’s process is “send us your files and we’ll let you know when it’s done,” you have no review step and no rollback. That is the version of migration that earned the scary reputation.

The carrier download cutover

This is the part agencies dread most, and it’s genuinely the least bad part — as long as you understand one fact: your IVANS mailbox belongs to your agency, not to your AMS vendor.

You are not re-establishing carrier relationships. You are pointing an existing pipe at a different destination. The carriers you already have download with stay connected. (The full mechanics are in how carrier downloads actually work.)

The sane sequence:

1. Connect the new system to your existing mailbox before cutover, and let it read alongside the old one.
2. Compare a few days of transactions in both systems. Same policies, same premiums, same dates? Good.
3. Work the new system’s review queue — a migrated book always produces a first wave of match exceptions as download reconciles against imported records.
4. Once transactions file cleanly for a week, stop working the old system.

One nuance worth planning for: download starts from the day it is switched on. It does not backfill. So the quality of your imported history determines what your book looks like for anything older than cutover day.

A realistic timeline

Large commercial books and legacy enterprise platforms run longer. Nothing about the process changes; the exception queues are just bigger.

How to prove nothing was lost

Do not eyeball it. Run these checks and write the numbers down, because “it looks right” is how agencies discover six months later that a line of business didn’t come across:

• Counts.Customers, active policies, and policies by line of business — old system versus new. Differences should be explainable, not surprising.
• Premium in force. Total written premium should reconcile within a rounding tolerance you decide in advance.
• Renewal calendar. Pull the next 90 days of renewals in both systems and compare. This is the check that catches a missing effective date field before it costs you a client.
• Spot-check twenty accountsacross lines — personal auto, home, a BOP, a work comp, something with a claim. Open each in both systems side by side and compare coverage detail, notes, and attachments.
• Note dates. Confirm your oldest note still shows its original date and not the import date. This one is quietly broken surprisingly often.
• Attachment sample. Open ten documents and confirm they open, are the right file, and are on the right account.

Then keep the old system’s export archived somewhere durable. Cheap, and the one thing you cannot recreate later.

Traps worth naming

• Announcing before exporting. Get your data out while everyone is still friendly.
• Migrating at renewal season.Pick your quietest stretch. There isn’t a good time, but there are much worse ones.
• Skipping the parallel period to save two weeks, and then having no reference when something looks wrong.
• Letting the parallel period run open-ended. Put a date on it. Two systems with no end date means neither is the source of truth.
• Training on demo data. Staff learn a system on their own accounts, not on a fictional one.
• Assuming the new vendor’s import handles your export format. Test with your real files during evaluation, not after you sign.

When not to switch

Honest answer: if your current system does what you need and the complaint is cosmetic, stay. Migration costs real weeks of attention you could spend writing business. The switch is worth it when the system is costing you something structural — downloads that don’t work with your main carriers, renewals falling through, commission you can’t verify, per-envelope fees on work you do daily, or a stack of bolted-on tools that don’t talk to each other. Those compound. Cosmetic annoyance doesn’t.

If you’re weighing specific platforms, our comparison pageslay out where each one is strong — including the cases where staying put is the right call.

Frequently asked questions