How to Migrate from One AMS to Another Without Losing Data
It is April, and the migration was supposed to take eight weeks. You signed the contract with your new agency management system in January, and the vendor's onboarding team was enthusiastic. Now, four months later, you have duplicate policy records sitting side by side with the originals, a document library that imported about 60% of its attachments before stopping, and three carrier download connections that have never successfully reconnected since the cutover. Your staff is running dual-system lookups on renewals, and the new AMS is technically "live" but operationally a liability.
This scenario is not unusual. It is, in fact, the modal outcome for independent agency AMS migrations. The failure modes are predictable, and most of them are avoidable if you understand what you are walking into before you sign anything. This guide covers what goes wrong, why, and how to structure a migration that gives your data — and your agency — the best chance of surviving intact.
Why AMS Migrations Fail: The Four Most Common Failure Modes
Most agencies treat an AMS migration as a software purchase. It is not. It is a data management project with a software component. The distinction matters because the risks are data risks, not software risks, and data problems often do not surface until weeks or months after the cutover.
Data mapping errors are the most fundamental failure mode. Every AMS has a different underlying data model. What one system calls a "policy" another calls a "coverage line," and what lives in a single record in your old system may need to populate three related tables in the new one. When the migration utility encounters a mapping ambiguity, it does one of three things: it makes a default assumption, it drops the record, or it flags an error. Default assumptions are the most dangerous because they produce no visible error — they just produce wrong data.
Incomplete attachment migration is the second most common failure. Document libraries are technically complex to migrate because attachments are typically stored as files in a folder structure that mirrors the record hierarchy, and that hierarchy rarely maps cleanly between systems. Vendors frequently migrate structured policy data successfully while leaving behind 30% to 50% of attached documents — endorsements, inspection reports, correspondence, signed applications. Those documents are not gone; they are sitting in the old system that you are paying to keep running, or they are gone if you decommissioned it.
Broken carrier downloads create the most acute operational pain. Carrier download connections — whether through IVANS or direct API — are configured at the carrier level and tied to specific agency codes, system credentials, and technical handshake parameters. A migration does not automatically transfer these configurations. Each connection needs to be rebuilt and tested individually. In agencies with 20 or 30 carrier connections, this process routinely takes two to three months of coordinated effort with carrier IT and IVANS support queues.
Staff adoption gaps are the failure mode that is hardest to measure but often does the most long-term damage. A migration can succeed technically while failing operationally because staff revert to paper files, spreadsheets, or the old system for the tasks they find confusing in the new one. Within six months, you have data living in multiple places and no single source of truth.
Understanding these four failure modes is the starting point. The rest of this guide is about mitigating each of them systematically.
Step 1: Audit Your Current Data Before You Leave
Before you have a single conversation with your new vendor's migration team, you need to know exactly what you have. This is the step most agencies skip, and skipping it means you have no baseline to measure the migration against.
A complete data audit for an AMS migration covers six categories:
Policy records. How many active policies do you have? How many policies in a historical archive (and how far back does that history go)? How many are in mid-endorsement or mid-renewal states that require special handling? Export a count from your current system and document it.
Client records. How many unique client records exist? Are there duplicates? If your current system has been in use for a decade, there are almost certainly duplicate client records — two entries for the same insured, or a personal lines client who also appears under a business name. Clean these up before migration, not after.
Documents and attachments. This is where most agencies are surprised. Run a report on your document library size — not just file count but total storage volume. Many agencies discover they have 80,000 or 120,000 attached files they never consciously thought about. You need this number before the migration because vendors will quote you based on record counts, and you need to verify that the attachment migration scope matches what you actually have.
Carrier connections. List every active carrier download connection: the carrier name, the IVANS mailbox identifier, the agency code, and who the carrier IT contact is. This list is your carrier reconnection checklist after cutover.
Custom fields and configurations. Does your current system have custom fields you have added over the years — fields for specific commercial lines data, tracking codes, referral sources, agency-specific classifications? Document every custom field and its purpose. The new system may not have an equivalent, and the data in those fields may need to go somewhere.
Email and correspondence history. Many modern AMS platforms store email correspondence linked to client records. This history is almost never fully migrated. Decide in advance whether you need it in the new system or whether you can archive it in the old system and access it on demand.
The output of this step is a written data inventory. Keep it. You will use it to verify the migration is complete.
Step 2: Understand What the New AMS Will Actually Import vs. What You Must Re-Enter
Every AMS vendor has a migration capability matrix — a document that specifies exactly which data objects they can import, from which source systems, and at what fidelity. Most vendors do not volunteer this document unless you ask for it by name. Ask for it before you sign.
The matrix will typically show you a grid of source systems (EZLynx, Applied Epic, HawkSoft, NowCerts, QQCatalyst, etc.) against data categories. A cell might say "full import," "partial import," or "manual re-entry required." Partial imports are where you need to dig: partial means some data in that category will transfer and some will not, and you need to understand which subset you are getting.
Pay particular attention to:
Policy history depth. Many systems import active policies and the prior policy term. Anything older typically requires a manual archive process or does not come over at all. If your E&O history depends on having complete policy records, this matters.
Endorsement and amendment history. The current policy structure often migrates. The history of how it got there — each endorsement, each mid-term change — frequently does not. You may arrive in your new system with a current policy declaration but no record of the three endorsements that produced it.
Notes and activity history. Internal notes attached to client records — call logs, meeting notes, follow-up reminders — have a low migration success rate. These are usually proprietary data structures that do not map cleanly to another system's schema.
Workflow states. If a policy is in the middle of a renewal workflow in your current system, the migration utility does not know what to do with it. These in-progress records almost always require manual handling at cutover.
Get the vendor's answer to each of these categories in writing. If the sales contact says "we import everything," ask them to define everything specifically, in the migration capability matrix, with your source system named. Vague verbal assurances are not contractual commitments.
Step 3: Negotiate Migration Support Terms in the Contract
Migration support is frequently treated as a line item add-on or as an assumed inclusion that is not formally scoped. Before you sign, make sure the contract specifies:
Who performs the migration. Is it the vendor's internal team, a certified implementation partner, or is it left to you? If it is an implementation partner, which one, and what is their specific experience with your source system?
What is included in the migration fee. Number of migration passes (typically you get one dry-run migration and one production migration), the data categories covered, the attachment volume included (many vendors cap this and charge per gigabyte beyond the cap), and the support hours available for post-migration data correction.
What the remediation process is. If the migration produces errors — duplicate records, missing attachments, broken relationships between data objects — who fixes them, on whose timeline, and at whose cost? Get a specific SLA for post-migration data correction.
Rollback terms. If the migration is materially defective, what is the exit path? Can you get a refund of implementation fees? What access do you retain to your data in the new system if you decide to leave before you have fully onboarded?
Vendors who resist specifying these terms in writing are telling you something important about how they handle migration problems.
For tools with published review coverage on this site, see EZLynx, Applied Epic, and HawkSoft for platform-specific notes on migration support models. If you are still deciding which AMS to move to, our AMS buyer's framework covers the full evaluation process.
It is also worth understanding how your chosen agency management system vendor defines "migration complete." Some vendors declare the migration complete when data has been transferred, regardless of whether carrier downloads work or staff can navigate the system. Define "complete" in the contract before you sign.
Step 4: Run a Parallel Period
A parallel period means operating both systems simultaneously — entering new transactions in the new system while the old system remains the production record of truth — for a defined duration, typically 30 to 90 days.
Most agencies want to skip this step because it is expensive and operationally painful. Running two systems means double data entry for new business, which consumes staff time and creates the risk of discrepancies between the two systems. The temptation is to hard-cutover: go live in the new system, turn off the old one, and deal with problems as they surface.
Hard cutover works when you have very high confidence in the migration accuracy. Most agencies do not, because they have not done the audit work in Step 1 and have not gotten the vendor's specific commitments in Step 3. If you have done those steps and the dry-run migration matched your data inventory within 2% to 3%, a shorter parallel period (30 days) may be reasonable. If you are uncertain about migration accuracy, run 60 days.
During the parallel period, assign specific staff members to run daily reconciliation checks on a sample of records — active policies, recent new business, recent endorsements. The reconciliation check should verify that the key data fields match between systems: insured name, policy number, effective date, premium, coverage limits, carrier. Any discrepancy goes on a correction log that the vendor's migration team addresses.
Also use the parallel period to test carrier downloads. Do not wait until you end the parallel period to discover that a carrier's download is not flowing correctly into the new system.
Step 5: Reconnect Carrier Downloads and Verify Data Accuracy
Carrier download reconnection is treated as a technical afterthought in most migrations, but it is the step that most directly affects your ability to operate on day one of production.
Use the carrier connection list you built in Step 1. For each carrier, you need to:
- Obtain the new AMS's IVANS mailbox identifier or API credentials
- Contact the carrier's agency services or IT team and provide the new credentials
- Set the carrier's system to direct downloads to the new mailbox
- Run a test download in the new AMS and verify that the data is arriving and mapping correctly to the right client and policy records
This process is sequential and slow because each carrier has its own timeline for making the credential change on their end. Some carriers respond in a day. Others have 3-to-4-week change request queues. Start this process during the parallel period, not after hard cutover.
After each download reconnects, verify a sample of downloaded transactions manually. Does the endorsement that came through carrier download actually apply to the right policy in the new system? Do the premium changes map to the right coverage fields? Carrier downloads have their own mapping configuration, separate from the initial data migration, and that configuration needs testing.
For a comparison of how different platforms handle carrier integrations, the EZLynx vs. HawkSoft comparison covers the IVANS integration differences between two commonly compared platforms.
Step 6: Staff Training and Adoption
The migration that works technically but fails operationally is a real category of failure, and it is underestimated because it is less visible than a broken carrier download or a missing policy record.
Staff adoption problems tend to emerge in two patterns. The first is the competence gap: staff know the old system's navigation intuitively and find the new system slow and confusing for the first few months. If there is no formal training and no proficiency benchmark, the slow period extends indefinitely, and staff invent workarounds — spreadsheets, sticky notes, dual lookups — that create data quality problems over time.
The second pattern is the legitimacy gap: staff who were not involved in the decision to switch systems, who see the migration problems firsthand, and who lose confidence that management is handling it competently. This produces active resistance — deliberate reversion to the old system, informal workarounds, and quiet hoarding of data outside the new system.
Addressing the competence gap requires formal, role-specific training before go-live, not generic vendor onboarding webinars. A CSR who handles personal lines renewals needs training on personal lines renewal workflows. A commercial lines producer needs training on submission creation and endorsement processing. The training content should be specific to the agency's workflows, not generic platform demonstrations.
Addressing the legitimacy gap requires honesty with staff about what went wrong in the migration and a clear escalation path for reporting data problems they discover. Staff who feel ignored when they report a data discrepancy stop reporting them.
See our overview of agency management systems and considerations around total cost of ownership for the full lifecycle of a platform transition — the training and adoption costs are frequently underestimated in initial TCO calculations.
What to Do When the Migration Goes Wrong
Even well-managed migrations produce problems. The question is whether you have the structure in place to address them before they compound.
For data integrity problems — duplicate records, missing fields, incorrect mappings — document each issue specifically: the record ID, the nature of the discrepancy, the expected value, and the actual value. Aggregate these into a correction log and submit it to the vendor's migration team with a specific remediation timeline requested. If the vendor is unresponsive, escalate to your contract's designated technical contact.
For attachment losses — documents that did not migrate — check whether the source system still has them before concluding they are gone. Many migrations run in a way that leaves the source system data intact until explicitly decommissioned. If the source data is still accessible, a second migration pass can often recover missing attachments.
For carrier download failures that persist beyond 30 days, escalate directly to the carrier's agency services manager rather than routing through general support queues. In parallel, contact IVANS directly if the issue is at the mailbox level rather than the carrier mapping level.
For complete migration failure — where the data integrity problems are so extensive that the new system cannot be used as a production system — you will need to invoke your contract's remediation provisions. This is the situation that makes the contract language in Step 3 matter. If you have rollback provisions and a refund mechanism for implementation fees, use them. If you do not have those provisions, you are negotiating from a weak position, which is why getting them in the contract before signing is non-negotiable.
Document every problem, every communication with the vendor, every date. If the situation escalates to a formal dispute, this record is your evidence.
AMS-Specific Migration Notes
Different AMS platforms have materially different migration support models, and the choice of destination system affects how the migration process will go.
EZLynx has a structured onboarding process with a defined set of source systems it imports from. Its data import templates are well-documented. The platform handles personal lines data more gracefully than complex commercial, and agencies with heavy commercial lines books should verify commercial data fidelity specifically during the dry-run migration. The EZLynx review covers the platform's data model in more detail.
Applied Epic migrations are typically performed by Vertafore-certified implementation partners rather than the vendor directly. The platform's data model is complex, and migrations into Applied Epic from smaller systems involve significant mapping work. Timeline expectations of 6 to 12 months for full production readiness are not unusual for larger agencies. See the Applied Epic review for context on the platform's architecture.
HawkSoft has developed a reputation for responsive migration support, particularly for agencies coming from legacy platforms. The platform has published import guides for several common source systems. The HawkSoft review covers the migration experience as reported by converted agencies. For a direct comparison between the two, the EZLynx vs. HawkSoft comparison addresses migration specifically.
NowCerts positions itself toward smaller agencies and has a lighter migration support model than the larger platforms. Self-service imports are common, and agencies with complex data or large document libraries should confirm specifically what the vendor will and will not handle. The NowCerts review covers the onboarding process in more detail.
Regardless of destination platform, the due diligence steps in this guide apply. The platform-specific notes above are starting points for understanding what you are walking into — not a substitute for the written commitments in your contract.
InsurAItools is editorially independent. We do not accept payment for placement or rankings. Our evaluation methodology is described at /methodology.
Our take: AMS migrations fail for the same reasons, in the same order, every time. The agencies that navigate them successfully do the audit work upfront, get specific contractual commitments on migration scope, run a parallel period long enough to surface problems, and treat carrier reconnection as a project with its own timeline and owner. The agencies that struggle skip those steps because the vendor's sales pitch made the migration sound straightforward. It is not. Build the project plan before you sign the contract, not after.
Frequently Asked Questions
Can I migrate my AMS data myself?
Technically possible for some platforms, but rarely advisable. Most AMS vendors provide migration utilities that only work with their certified data formats, and a self-managed migration introduces significant risk of mapping errors. If you proceed without vendor support, hire a data consultant who has done the specific source-to-destination migration before — not just someone familiar with one of the two platforms. The cost of a specialist is almost always less than the cost of cleaning up a failed self-migration.
What data cannot be migrated between AMS platforms?
Attachments and document libraries are the most common casualty. Custom field configurations, email correspondence history, and workflow automation rules almost never migrate cleanly. Policy history prior to a certain cutoff date is also frequently truncated. Always get a written list of what will and will not transfer before you sign the contract. This is non-negotiable — verbal assurances from sales do not survive the implementation handoff.
How long does an AMS migration typically take?
Vendors often quote 6 to 12 weeks. In practice, full production readiness — including stable carrier downloads, verified data accuracy, and staff working at normal speed — typically takes 4 to 9 months for agencies with more than 500 policies. The technical data transfer is usually the fastest part; staff adoption and carrier reconnection are where time bleeds away. Plan your contract timing, staff bandwidth allocation, and client communication accordingly. If the vendor's quote is 8 weeks and you have 40 carrier connections and 3,000 policies, the 8-week number describes the data transfer, not operational readiness.