An AMS migration is sold as a data project. Clients, policies, activities, and accounting move from one system to another, and the vendor or a conversion specialist handles most of it.
The part that goes missing is not in the database. It is how your people use the system: which screen they check before issuing a certificate, which field means "do not auto-renew" at your agency, which carrier's download always needs a manual fix. None of that converts. If it is not written down before cutover, it lives only in memory, and memory gets overwritten fast when everything on the screen is new.
The same phases apply whether an agency is moving to Applied Epic, Vertafore AMS360, HawkSoft, EZLynx, or another agency management system.
Product names are trademarks of their owners. SopWow is not affiliated with them.
What are the phases of an AMS migration?
Seven, in this order:
- Decide and plan. Choose the system, set the date, name the owners.
- Document current workflows. Before cutover, while the old system still works.
- Map and clean the data. Decide what moves, fix it before it moves, and test.
- Run in parallel. A defined period where the old system is still available.
- Rewrite SOPs in the new system. Record each workflow again after cutover.
- Train. On real tasks, by role, in order of frequency.
- Review after cutover. At set points, with a list.
Phases 2 and 3 overlap in time. Phase 2 is the one most agencies skip, and the one this guide argues for hardest.
How should an agency decide and plan the migration?
Start with why you are moving, in writing. "The old system is end of life", "we need better commercial lines workflow", and "we are merging with another agency" lead to different priorities, and a written reason settles arguments later.
Then plan the basics:
- An internal owner. One person inside the agency, not only the vendor's project manager, who owns the date, the decisions, and the checklist.
- A cutover date that avoids your peak. Stay away from your heaviest renewal period and from month-end close. Ask the vendor how long each phase took for agencies of your size and mix of lines, and plan with margin.
- A decision log. Every choice about setup, data, and process gets one line: what was decided, by whom, and why. Six months later, someone will ask why a field is set the way it is.
- Scope. Which lines, locations, and modules move now, and which move later.
- Access to the old system after cutover. Read-only access, an export, or both, and for how long. Ask your counsel how long you need to keep records available and in what form, and ask the vendor what they offer.
Why document current workflows before cutover?
Because the old system's clicks die at cutover, but the decisions don't.
"Click Policies, then Endorsements, then the third tab" will be useless the day the new system goes live. But "before issuing a certificate with additional insured wording, confirm the endorsement exists on the policy" is just as true in the new system as it was in the old one. So is "commercial auto changes for this carrier go through the portal, not the underwriter's email". Those decisions are the agency's real operating knowledge, and they are what gets lost.
If the old workflows are written down, the migration team can map each one to the new system on purpose. If they are not, people rebuild them from memory under pressure, differently from each other, in the middle of learning new screens.
How to do it:
- Start from an inventory. List workflows by line and role, and score them by frequency, error cost, and how few people know them. There is a full method in how to document insurance agency workflows.
- Capture real runs in the old system. The person who does each task best does a real example while it is captured, not a demonstration.
- Pull out the decisions. For each workflow, list every point where someone chooses: which option, which carrier route, when to escalate. Put variation in decision tables.
- List the workarounds. Every agency has fixes for old-system problems: a field used for something other than its label, a report run twice. Write them down. Some will be unnecessary in the new system, and some will need a new home.
- Start early. Documentation can begin as soon as the decision to migrate is made. It needs the old system, not the new one.
How should you map and clean up the data?
Decide what moves, clean it before it moves, and test the result. Your vendor or conversion specialist will define what their conversion carries over and how. Ask them directly, in writing, about each category below.
Common categories to map:
- Clients, contacts, and relationships between accounts
- Policies: active, and how many years of expired history
- Coverage detail: how much moves as structured data and how much as attachments or notes
- Activities, notes, and open follow-ups or suspense items
- Attachments and documents
- Carriers, writing companies, and how carrier names are standardized
- Producers, service teams, and commission splits
- Accounting: open receivables, unapplied cash, and history
- Certificate holders and saved certificate wording
- Custom fields, and what each one actually means at your agency
- Carrier download setup, and what has to be set up again
Clean up in the old system, before conversion. Merge duplicate clients. Close out policies still marked active that are not. Standardize carrier and producer names. Fill or flag missing contact details. Decide what to leave behind, such as long-inactive prospects, instead of carrying clutter into a clean system.
Then test. Most conversions include at least one trial run. Pick a sample of real accounts across lines, including the messy ones, and check them field by field against the old system. The workflows you documented are the test script: can each one be done in the new system with the converted data?
Why run the old and new systems in parallel?
To catch what the conversion or the setup missed while you can still look it up. A parallel period is when the new system is live for daily work and the old one is still available, usually read-only, for reference and checking.
Define it before it starts:
- What is checked in both. Full double entry is expensive. Pick specific checks instead: new certificates compared against the old record, accounting reconciled in both through the first month-end, download results compared for key carriers.
- Who checks. Named people, not "everyone".
- When it ends. A date, plus the conditions that must be true to end it.
Keep a shared list of every discrepancy found, who is fixing it, and whether it points to a data problem, a setup problem, or a missing SOP.
How do you rewrite SOPs after cutover?
Record them again, in the new system, on real work. Do not try to edit old screenshots into new ones.
The same person who did the task best in the old system does it in the new one, once the setup is stable. The decisions from the pre-cutover documentation carry straight over: the decision tables, the escalation rules, the carrier reference table. What changes is the path through the screens, the field names, and sometimes the order of steps.
Some tips:
- Rewrite in order of frequency. Certificates, endorsements, and common service tasks first, because people need them on day one.
- Wait for setup to settle. Recording a workflow the day before the vendor changes a setting means recording it twice.
- Check the old workarounds. For each workaround on your list, decide if the new system makes it unnecessary, needs a new workaround, or needs a setup change.
- Archive, do not delete. Keep old-system SOPs in an archive folder. During the parallel period people will need them to find things in old records.
How should you train staff on the new system?
Vendor training teaches the system. Your SOPs teach your agency's way of using it. Staff need both.
Train by role, on the tasks each person does most often, in the order they happen. A CSR needs certificates and policy changes first. Accounting needs reconciliation and invoicing. Producer support needs prospect entry and submissions.
Name a few super users, people who learn the new system early and deeply, and make them the first stop for questions. Give everyone a shared question log. Answer it at set times, and put every useful answer into the relevant SOP. Expect productivity to dip for a while and plan staffing around it rather than pretending it will not happen.
What should the post-cutover review cover?
Hold it at set points, such as after the first week, after the first month-end close, and after the first full renewal cycle. Use the same list each time:
- Data spot checks on a sample of accounts, including the complicated ones
- Carrier downloads: working, failing, or partial
- Open follow-ups and suspense items: nothing lost in conversion
- Accounting: receivables, commissions, and bank reconciliation all agree
- Certificates and endorsements: issued correctly, with the right wording
- The question log: what it shows about missing or wrong SOPs
- New workarounds staff have invented, and whether they should become setup changes or SOPs
- Old-system access: still needed, and until when
Each review ends with a short list of fixes, owners, and dates, added to the decision log.
What goes on an AMS migration checklist?
A condensed version of this guide. Copy it into your project tracker.
Decide and plan
- Written reason for the move
- Internal owner named
- Cutover date chosen, away from peak renewals and month-end
- Decision log started
- Scope set: lines, locations, modules
- Old-system access and records retention confirmed with the vendor and counsel
Document current workflows
- Workflow inventory by line and role, scored
- Top workflows captured from real runs in the old system
- Decisions and decision tables written for each
- Workarounds listed
Map and clean data
- Vendor's conversion scope confirmed in writing, category by category
- Duplicates merged, stale policies closed, names standardized
- Trial conversion checked on real sample accounts
- Documented workflows run as the test script
Parallel run
- Checks, checkers, and end conditions defined
- Discrepancy list kept and worked
Rewrite SOPs
- Top workflows recorded again in the new system, by frequency
- Decision tables carried over and rechecked
- Old SOPs archived, not deleted
Train
- Role-based training on the most frequent tasks
- Super users named
- Question log running, answers folded into SOPs
Review
- Reviews held after week one, first month-end, and first renewal cycle
- Fixes, owners, and dates added to the decision log
Where does SopWow fit in an AMS migration?
At the two documentation steps. Before cutover, the person who knows each workflow does it once in the old system with the SopWow recorder running in their browser. SopWow drafts the SOP, asks about the decisions a recording cannot explain, and flags anything it added until a person approves it. After cutover, they record again in the new system, and the decisions carry over. There is more on SopWow for insurance agencies.
One limit matters here: SopWow only records work in the browser. Steps in a desktop application, a remote desktop session, or Citrix are not captured and can be added by hand in review.
For AMS vendors and platforms that onboard many agencies, SopWow offers wholesale pricing per onboarded agency. Contact the SopWow team about wholesale onboarding packs.
Frequently asked questions
How long does an AMS migration take?
It depends on the agency's size, lines of business, data quality, and the vendor's conversion process. Ask the vendor for their typical timeline for agencies like yours, and add margin for documentation, cleanup, and a parallel period.
What data does not convert in an AMS migration?
That depends on the vendor and on the two systems involved, so get the answer in writing, category by category. What never converts is the agency's own know-how: why things are done a certain way, workarounds, and account-specific handling. That has to be documented.
Should we document workflows before or after switching AMS?
Both. Before cutover, capture how work is done and, most of all, the decisions behind it. After cutover, record the workflows again in the new system. The decisions carry over; the clicks do not.
Do we need to run the old and new AMS in parallel?
Most agencies benefit from a defined period where the old system stays available, usually read-only, for checking and lookups. Decide in advance what gets checked in both systems, by whom, and when the period ends.
How do you train staff on a new agency management system?
Combine the vendor's system training with your own SOPs for your agency's way of working. Train by role, starting with each role's most frequent tasks, name super users, and keep a shared question log whose answers go back into the SOPs.
Ready to record your agency's workflows before cutover?
Start with the workflow your team does most often, while the old system still works. Vendors and platforms onboarding many agencies can ask about wholesale onboarding packs.