The implementation goes fine. The demo goes fine. The training goes fine.

Then you move the data.

Data migration is the part of an AMS project that most agencies don't plan for carefully, because it sounds like a technical detail. You're moving files from one system to another. How complicated can it be?

Complicated enough that it's where a disproportionate number of agency software implementations go wrong.

Here's what I've seen happen, and what to do differently.

Why agencies underestimate it

The vendor presents migration as a solved problem. They've done it hundreds of times. They have a process. They have tools. It's included in the implementation package.

All of that can be true and the migration can still take twice as long as anyone projected, with data quality issues that surface six months after you go live.

The reason is simple: the vendor knows their system. They don't know your data. And nobody knows your data as well as you think you do until you try to move it somewhere else.

Your existing data was built up over years, maybe decades, in a system that had its own structure, its own quirks, its own workarounds. Policies that got entered one way in 2019 and a slightly different way in 2022. Client records that got duplicated when someone added a spouse's name wrong and created a second file. Documents filed under client names instead of policy numbers because that's how one CSR always did it.

None of this is unusual. It's just reality. And it becomes your problem the moment you try to move that data into a new system with a different structure and different expectations.

What the data actually looks like when you dig in

Ask your team to pull 50 random client records from your current system. Not your cleanest accounts. Random ones.

Look at them honestly.

How many have complete contact information? How many have missing policy dates? How many have notes that reference things nobody on your current staff remembers? How many have documents that are named in ways that no longer mean anything?

Most agencies find duplicates. Most find incomplete records. Most find a handful of accounts where the data is just confusing, because the person who set it up that way left three years ago.

This isn't a criticism. It's how data accumulates in any system that gets used every day over many years. The issue is that your new AMS doesn't care about context or history. It's going to process what you give it, and anything that doesn't fit its structure is going to create a problem you'll deal with after go-live.

What the vendor does versus what you have to do

This distinction matters more than most agencies realize.

The vendor migrates the data. You're responsible for the data you give them.

That means: if your source data is duplicated, you'll get duplicated records in the new system. If your document naming is inconsistent, it'll be inconsistent on the other side. If your client addresses are out of date, they'll be out of date in your new platform too. The migration tool doesn't clean, it moves.

What that means practically is that data cleanup is almost always your team's job, not the vendor's. And it's almost always more time-consuming than anyone projected, because you can't speed up humans reviewing and correcting individual records.

Some vendors offer data cleanup services. Some of those services are good. Ask about this specifically, get concrete examples of what they'll clean and what they won't, and price it out before you agree to it.

The specific things that go wrong

Not in the abstract. Here's what actually happens.

Policy records that don't map. Your current system has fields your new AMS doesn't, or vice versa. The data that lived in one place has nowhere obvious to go. You either lose it, shove it into a notes field where it's technically present but practically useless, or go through it record by record.

Attachments that don't come through. Documents don't always migrate cleanly. They may come through without their associations to the right client or policy, or they may not come through at all if they're in a format the new system doesn't recognize.

Duplicate records that multiply. If you have 400 duplicate client entries going in, you may end up with 800 on the other side, depending on how the migration tool handles matching logic. Then you're spending weeks cleaning up in your new system instead of your old one.

Carrier and policy data that's incomplete. Renewal dates, commission structures, policy terms — these get messy. If your staff has to manually verify or correct carrier data after go-live, you've added a significant amount of work right at the moment everyone is already adjusting to a new system.

Staff who don't trust the data. This one's underrated. If your CSRs go to pull up a client record in the new system and find something that looks wrong, they're going to check the old system. Then they're going to start defaulting to the old system. Then you've got two systems running in parallel, neither one authoritative.

What to do before the migration starts

Audit your data first. Before you sign anything, do an honest assessment of your data quality. You don't need a consultant for this. Pull a sample, look at it, and estimate how much cleanup is actually needed.

Decide what you're migrating. You probably don't need to migrate everything. Active policies, current clients, recent documents — yes. Historical records from clients you haven't talked to in ten years — maybe not. Every record you migrate is a record that has to be validated. Be selective.

Assign someone internal to own the migration. The vendor will do the technical work. You need a person on your side whose job it is to coordinate, review, approve, and escalate. This can't be someone who's also running their normal workload at full capacity. It has to be someone with actual hours carved out.

Build in a parallel-run period. Plan to run both systems simultaneously for at least a few weeks after go-live. Not forever. But long enough that your staff can verify they're seeing what they expect to see in the new system before you shut off the old one. This adds time to the project and it's worth it.

What to ask the vendor before you sign

Get specific answers to these questions before you agree to anything:

How does your migration tool handle records that don't match your data structure? What's the error rate you typically see? What does the exception handling process look like?

Who on your team is responsible for the migration? What's their experience level? Can I speak to them directly?

What's your cutover process? When do we turn off the old system? What's the rollback plan if something looks wrong after go-live?

How do you handle documents? What file formats do you support? Are documents associated to their records automatically or does someone have to verify that?

What happens to data that can't be migrated? Do we get a report of what was left behind and why?

If the answers are vague, push for specifics. A vendor who's done this well many times will have specific answers. Vagueness about migration is usually a signal that it's been a problem they'd rather not discuss in the sales process.

The honest timeline

Most agencies project two to four months for a full AMS implementation. Data migration, done properly, often accounts for half of that or more — especially if there's meaningful cleanup involved.

The agencies that handle migration well are the ones that treat it as a project in its own right, not a step in someone else's project. They start the data audit early. They give the cleanup work dedicated time. They run parallel systems long enough to feel confident.

The agencies that end up with migration problems are usually the ones that treated it as a handoff. They assumed the vendor would figure it out. They didn't audit the source data ahead of time. They went live before they were ready because the go-live date felt fixed.

Your go-live date is not more important than your data quality. If the migration isn't clean, move the date. A delayed go-live is a manageable problem. Corrupted or missing data in your live system is a much harder one.

*Mitch Gibson evaluates agency technology from the buying side — no platform affiliations, no vendor relationships. For more on what agencies get right and wrong with tech decisions, [subscribe to the newsletter](#) or [listen to the podcast](#).*