The Complete Insurance Agency Data Conversion Checklist

What Your Agency Should Actually Be Doing Before, During, and After an AMS Migration

Moving from one Agency Management System to another is one of those projects that can look deceptively simple from the outside.

You have data in one system. You need that data in another system. Export it, map it, import it, and move on.

Anyone who has actually been through a large insurance data conversion knows it doesn't work that way.

An agency management system isn't just a database containing names and policy numbers. After years of daily use, it becomes a historical record of the agency itself. Clients, contacts, policies, activities, attachments, producers, carrier relationships, branches, departments, accounting information, and years of decisions all become interconnected.

That is why we look at data conversions very differently at InsurCore.

A successful conversion is not simply about getting records to load into the destination system. The real objective is getting the right data, into the right places, with the right relationships, and being able to prove that it happened correctly.

If you're moving to Applied Epic—or consolidating several acquired agencies into an existing Epic environment—there is also another reality to consider: your agency still has to operate while all of this is happening.

Clients are still calling. Renewals are still processing. Producers are still writing business. Accounting still has deadlines. Carrier downloads don't stop because you're changing systems.

That is why the preparation around a conversion matters almost as much as the technical conversion itself.

This is the checklist we believe agencies should actually be using.

Not simply a list of things your staff should go clean up before your conversion company arrives, but a practical look at who needs to be involved, what decisions need to be made, what your conversion partner should be doing for you, and what you should expect as you work toward go-live.

Start With the Right Person Leading the Conversion

One of the first things we want to understand at the beginning of a conversion is who will be leading the project from the agency side.

This person matters far more than many agencies initially realize.

If you're converting into Applied Epic, the internal project leader should not simply be someone who is organized or good at managing a spreadsheet. They need to understand Epic. More importantly, they need enough practical knowledge of Epic to make decisions and manipulate the environment when necessary.

Throughout a conversion there will be questions about how information should appear in Epic, how your agency and branch structure is configured, how users and producers should map, what codes should be used, how policy information should be represented, and what the destination environment expects.

Those are not decisions someone should be learning how to make in the middle of the conversion.

This does not mean every agency needs to have a full-time Epic database administrator on payroll before beginning a migration. Many don't.

But somebody needs to fill that role.

For agencies that already have an experienced Epic administrator or application specialist, that person becomes one of the most valuable members of the conversion team.

For agencies that don't, InsurCore can manage that process end to end.

We've talked before about the value of using a Fractional Database Administrator, and conversions are one of the clearest examples of where that model makes sense. Instead of assigning the project to an operations employee who is simultaneously trying to learn Epic, coordinate the implementation, answer conversion questions, and do their normal job, an experienced administrator can step in and manage those responsibilities throughout the engagement.

The rest of the agency should still be involved. Leadership needs visibility. Department heads need to answer business questions. Accounting needs to participate where accounting information is involved. Your implementation and training partners need to stay aligned.

But there should be one knowledgeable person who understands the destination system well enough to lead the technical and operational conversation.

If that person doesn't exist internally, that is a gap you want to solve before the conversion gets complicated, not after.

Conversion Leadership Checklist

☐ Identify the person responsible for the agency-side conversion decisions
☐ Confirm that person has strong working knowledge of Applied Epic
☐ Identify an executive sponsor
☐ Identify accounting and department-level contacts
☐ Establish a recurring weekly conversion meeting
☐ Determine whether a Fractional Database Administrator is needed
☐ Clearly separate data-conversion responsibilities from workflow and training responsibilities

Your Agency Should Not Have to Become the Data Cleanup Team

This is an area where we disagree with a lot of traditional conversion advice.

You'll frequently hear agencies told that they need to spend the months before conversion cleaning their databases.

There is certainly value in good data hygiene. But if you've hired a professional data conversion company, we don't believe your employees should spend weeks manually hunting through a legacy database trying to figure out what needs to be cleaned.

That is part of our job.

When InsurCore receives your source data, one of the first things we do is analyze what is actually there.

That can mean restoring a SQL backup, examining DBF or Paradox files, reviewing exported spreadsheets, working through APIs, evaluating attachment directories, or dealing with a combination of several sources.

We aren't simply looking for whether the database opens.

We're trying to understand the story the data is telling us.

Are there duplicate entities?

Are the same carriers represented several different ways?

Are policy records missing relationships?

Do inactive employees still own historical business?

Are attachments properly associated with clients and policies?

Do dates make sense?

Are records using codes that don't have an obvious destination in Epic?

Are we dealing with information that was consistently entered over the years, or did different offices and different users follow completely different conventions?

Those findings become part of the conversion process.

We review them with the agency during the weekly meetings we are already having. We show you what we've found, explain why it matters, and determine the correct business decision together.

Once that decision is made, InsurCore handles the changes.

We do not expect your account managers or operations staff to spend nights and weekends manually updating thousands of records just so the data can be converted.

That distinction is important.

Your team provides the business knowledge.

We provide the data engineering.

There will always be situations where only the agency can tell us the answer. Maybe two carrier records look nearly identical but actually represent different relationships. Maybe an old producer code still needs to exist because it owns historical business. Maybe a branch that appears unused still matters for reporting.

We need your team's knowledge for those decisions.

But once the answer is known, the technical execution belongs with us.

Data Review and Cleansing Checklist

☐ Secure the complete source-system backup
☐ Confirm that attachments and external document stores are included
☐ Inventory major record types
☐ Identify duplicate or inconsistent records
☐ Review carrier and company structures
☐ Review employees, producers, brokers, and inactive users
☐ Identify orphaned or improperly linked attachments
☐ Identify missing or inconsistent policy relationships
☐ Document conversion exceptions
☐ Review findings during weekly project meetings
☐ Approve the appropriate cleanup or mapping decision
☐ Have InsurCore implement the approved changes

Make Sure You Actually Have All of the Data

This sounds obvious, but it deserves its own section.

One of the most expensive mistakes an agency can make is assuming that everything it sees in the old system is stored in one convenient database.

It isn't always.

We've worked with source environments where the primary database contained the customer and policy information, while attachments were stored somewhere completely different. Other systems might have document directories, external file stores, archived databases, SQL backups, separate images, or historical files that require their own extraction process.

Before we talk about converting anything, we want to understand what exists.

Clients.

Contacts.

Policies.

Activities.

Attachments.

Accounting information, if applicable.

Users.

Companies.

Branches.

Departments.

And anything else that matters to the historical record of the agency.

You do not want to discover three days before go-live that somebody forgot about ten years of scanned policy documents sitting on another server.

That is why a proper data inventory happens early.

We also strongly recommend keeping access to the old environment until the new data has been converted, reconciled, and accepted. A source system can be inconvenient or expensive to maintain temporarily, but losing access before the extraction and verification work is complete can create a far larger problem.

Source Data Checklist

☐ Obtain the production database backup
☐ Locate attachment storage
☐ Identify archived databases
☐ Identify supplemental exports or spreadsheets
☐ Confirm accounting sources
☐ Identify integrations that may contain information not stored in the primary database
☐ Document the source-system version
☐ Preserve source-system access through validation

Mapping Is Where the Conversion Really Takes Shape

People often describe conversion mapping as though we're taking Column A from the old system and putting it into Column B in Epic.

Sometimes that is exactly what happens.

A lot of the time, it isn't.

Different agency management systems represent the same business concepts in very different ways. Even two agencies using the same source AMS can have dramatically different data because of how each agency configured and used the platform over the years.

Line-of-business codes are a good example.

A code in one agency may mean exactly what its name suggests. At another agency, the same-looking code may have developed a completely different internal meaning because somebody created it fifteen years ago for a specific workflow.

The same problem can exist with carriers, branches, producers, departments, policy statuses, activity codes, broker relationships, agency structures, and user assignments.

Applied Epic also has its own rules and relationships that need to be respected.

This is why the person representing the agency during mapping needs to understand Epic.

The mapping process is not simply a technical exercise. It is where business knowledge and technical conversion work meet.

Our job is to extract the source values, understand how they are actually being used, identify the appropriate Epic destination, and document the transformation.

Your job is to help us answer the questions only your agency can answer.

Once those decisions are made, they should remain documented throughout the project. Nobody should be reinventing mappings during the final production conversion because a decision made three weeks earlier disappeared in somebody's inbox.

Mapping Checklist

☐ Agency and branch structure
☐ Departments
☐ Employees and producers
☐ Carrier/company records
☐ Billing and issuing company relationships
☐ Lines of business
☐ Policy statuses
☐ Activity types
☐ Client and contact classifications
☐ Custom values
☐ Historical users
☐ Broker relationships
☐ Required Epic lookup codes
☐ Conversion-specific exceptions

Test With Real Data, Not Assumptions

This is where the conversion becomes tangible.

We can spend weeks talking about mappings, reviewing schemas, analyzing database tables, and documenting decisions, but eventually we need to see what the finished data actually looks like inside Epic.

That is what the test conversion is for.

A good test conversion isn't simply a demonstration that the import process runs.

It should answer much more useful questions.

Did the client arrive correctly?

Are the associated contacts where they belong?

Does the policy appear under the correct customer?

Are dates correct?

Is the policy assigned to the appropriate company and line of business?

Did activities maintain their relationship?

Are attachments attached to the right account?

Are subjects and descriptions readable?

Are historical users represented properly?

Does the data make sense to somebody who works inside Epic every day?

That final question matters.

Data can technically pass an import and still be operationally wrong.

This is why the agency-side Epic expert is so important. A developer can verify that a policy record imported successfully. An experienced Epic administrator can tell you whether that record actually belongs where it landed.

At InsurCore, we also reconcile what we send against what comes back from the import process. Record counts matter. Exceptions matter. Failures matter. We want to understand what succeeded, what did not, and why.

If ten thousand attachments were submitted and nine thousand eight hundred were accepted, we do not consider "most of them worked" to be reconciliation.

We want to know what happened to the other two hundred.

Test Conversion Checklist

☐ Select representative customers for testing
☐ Include simple and complex accounts
☐ Include different lines of business
☐ Include accounts with historical activities
☐ Include accounts with attachments
☐ Include inactive or historical relationships where appropriate
☐ Review the converted records inside Epic
☐ Compare source and destination counts
☐ Review import exceptions
☐ Correct mapping or transformation issues
☐ Rerun testing when material changes are made
☐ Obtain agency-side approval before production

Don't Ignore Attachments and Activities

Policies tend to receive the most attention in a conversion because they are the obvious part of the agency's book of business.

But some of the information your staff depends on every day isn't contained in the policy record itself.

It's in the activity history.

It's in correspondence.

It's in scanned documents.

It's in attachments.

It's in notes left by an employee who hasn't worked at the agency in seven years.

That historical information matters.

An account may look perfectly fine from the policy screen while still being almost useless operationally if the activity history and supporting documents didn't follow it.

This is why we treat activities and attachments as their own conversion workloads rather than assuming they will take care of themselves.

They also present different technical challenges.

Attachments may be stored outside the primary database. File names may not match the identifiers visible to users. An attachment can physically exist but still become useless if it is associated with the wrong customer after conversion.

Activities can have similar problems. Dates, users, subjects, descriptions, agency assignments, and branch relationships may all need to conform to destination-system requirements.

These are exactly the kinds of areas where reconciliation matters.

Plan the Database Freeze Before You Need It

Eventually, every production conversion reaches a point where we need a final snapshot of the source environment.

From that point forward, you have to assume that new entries made into the old system are not going to magically appear in the new one.

That is the database freeze.

It sounds disruptive when you explain it for the first time, but with a good plan, it is manageable.

The agency does not stop operating.

Employees still answer calls. Clients still need endorsements. Policies still need to be serviced. Payments may still arrive.

What changes temporarily is how that information is handled.

During the freeze, your source AMS should generally become a reference system rather than the place employees continue entering new work. Staff can look information up when necessary, but new activity needs to follow the temporary process established before the freeze begins.

For many service requests, carrier portals can keep the agency operating normally. If an insured needs an ID card, policy change, billing assistance, or another carrier-level service, that work can frequently still be completed directly with the carrier.

The important part is documenting what happened.

If an endorsement is processed during the freeze, keep the supporting confirmation. If a client gives you a new phone number, track it. If correspondence needs to become part of the permanent customer record, retain it so it can be entered or attached after the new environment becomes available.

This is not the time to invent the process.

A week or two before the freeze, your staff should already know exactly what they're supposed to do.

We've gone deeper into this topic in our article about keeping your agency operating during a data conversion, and that makes a natural companion piece to this checklist.

Database Freeze Checklist

☐ Set the final source-data cutoff
☐ Communicate the date to every affected employee
☐ Explain what read-only means
☐ Confirm carrier portal access
☐ Create the temporary activity-tracking process
☐ Establish a document-retention location for freeze-period activity
☐ Establish the accounting cutoff process
☐ Assign responsibility for post-go-live catch-up entry
☐ Confirm the final backup procedure
☐ Confirm InsurCore has received the final production data

Accounting Needs Its Own Plan

Accounting deserves special treatment because money does not care that you're in the middle of a software migration.

Deposits continue.

Carrier statements continue.

Agency-bill transactions continue.

Commissions continue.

The worst possible approach is having some transactions entered into the old system, some into the new system, and nobody completely sure where the dividing line was.

There needs to be a cutoff that everyone understands.

Depending on the scope of your conversion, the accounting strategy can vary considerably, and this is one of the areas where your implementation and accounting partners need to be involved early.

What matters is that the source records are reconciled to an agreed point, the destination opening position is understood, and any freeze-period transactions have a documented home.

Do not wait until the Friday before go-live to start talking about that.

Production Conversion Should Be Boring

That may sound strange coming from a company that does data conversions for a living, but it is absolutely true.

We want the final production conversion to be boring.

By production weekend, we should already understand the source data. The mappings should already be decided. Test records should already have been reviewed. Exceptions should already be understood. The import process should already have been exercised.

Production should not be the first time we learn something important about your database.

The work becomes a controlled execution of a process we've already tested.

That doesn't mean unexpected issues can never occur. Real databases are complicated, and there will always be edge cases.

But there is a huge difference between solving an edge case and discovering during production that nobody ever decided how half the agency's carriers should map.

Preparation is what creates that difference.

Production Conversion Checklist

☐ Final backup received
☐ Source data verified
☐ Final mapping decisions locked
☐ Cleansing changes applied
☐ Import files generated
☐ Record counts documented
☐ Conversion executed
☐ Import results captured
☐ Failures and exceptions reconciled
☐ Attachments verified
☐ Activities verified
☐ Sample customer records reviewed
☐ Agency-side Epic administrator performs validation
☐ Production conversion accepted

Go-Live Isn't When the Project Ends

There is a tendency to treat Monday morning as the finish line.

Everybody logs into Epic. The data is there. The project is done.

Not quite.

The first several days after go-live are where we confirm that the converted environment behaves the way everyone expected when real users begin working with it.

Carrier downloads start flowing.

Employees begin navigating converted accounts.

Reports get run.

Historical policies get opened.

Attachments get searched.

Accounting processes begin operating in the new environment.

This is when small issues that were impossible to anticipate in a test sample can surface.

That is normal.

What matters is having a structured process for handling those issues rather than allowing twenty people to email twenty different problems to twenty different people.

During stabilization, conversion-related findings should be gathered, reviewed, prioritized, and either corrected or routed to the appropriate party.

And this is also where responsibilities need to remain clear.

InsurCore handles the data conversion.

If there is a data issue caused by mapping, transformation, importing, relationships, or another part of the conversion, we need to know about it.

Workflow design, end-user training, and broader Epic operational consulting may belong with your implementation or consulting partner unless you've separately engaged us for administration support.

Keeping those responsibilities clear prevents the agency from getting bounced between vendors when something needs attention.

The Full Insurance Agency Data Conversion Checklist

Project Leadership

☐ Assign a knowledgeable Applied Epic project leader
☐ Confirm the project leader can work within and administer Epic
☐ Identify an executive sponsor
☐ Identify accounting stakeholders
☐ Identify department stakeholders
☐ Establish weekly conversion meetings
☐ Engage a Fractional Database Administrator if needed

Source Data

☐ Secure database backup
☐ Secure attachments
☐ Locate archived data
☐ Identify supplemental spreadsheets or files
☐ Confirm historical system access
☐ Inventory clients
☐ Inventory contacts
☐ Inventory policies
☐ Inventory activities
☐ Inventory attachments
☐ Inventory employees and producers
☐ Inventory carrier/company records

Data Analysis and Cleansing

☐ Analyze duplicate records
☐ Identify inconsistent carrier records
☐ Identify inactive or historical users
☐ Identify broken relationships
☐ Identify orphaned attachments
☐ Identify invalid or unusable values
☐ Review findings with InsurCore
☐ Approve business decisions
☐ Allow InsurCore to perform agreed cleanup

Mapping

☐ Agency
☐ Branch
☐ Department
☐ Employee
☐ Producer
☐ Broker
☐ Carrier
☐ Issuing company
☐ Billing company
☐ Line of business
☐ Policy status
☐ Activity codes
☐ Client classifications
☐ Required lookup values
☐ Historical values
☐ Conversion exceptions

Testing

☐ Select representative accounts
☐ Perform test conversion
☐ Review clients and contacts
☐ Review policies
☐ Review activities
☐ Review attachments
☐ Review historical users
☐ Compare source and destination
☐ Reconcile import counts
☐ Review failed records
☐ Correct mapping
☐ Retest significant changes
☐ Obtain approval

Freeze Preparation

☐ Select cutoff date
☐ Notify employees
☐ Establish read-only expectations
☐ Verify carrier portal access
☐ Create temporary tracking process
☐ Establish accounting cutoff
☐ Establish freeze-period document storage
☐ Establish post-go-live catch-up process
☐ Take final production backup

Production

☐ Verify final data
☐ Run transformations
☐ Generate import files
☐ Perform production import
☐ Capture success and failure counts
☐ Reconcile clients
☐ Reconcile policies
☐ Reconcile activities
☐ Reconcile attachments
☐ Review test accounts in production
☐ Obtain final sign-off

Go-Live and Stabilization

☐ Verify user access
☐ Begin carrier downloads
☐ Enter documented freeze-period changes
☐ Upload freeze-period documents
☐ Review priority customer accounts
☐ Validate converted historical information
☐ Centralize conversion issues
☐ Hold short stabilization meetings
☐ Escalate data-conversion issues to InsurCore
☐ Route workflow/training issues to the appropriate implementation partner
☐ Complete final reconciliation

What We Want Agencies to Take Away From This

A good insurance data conversion should not require your agency to temporarily become a software company.

You shouldn't have to hire a team of database developers.

Your account managers shouldn't be spending evenings cleaning thousands of records.

Your COO shouldn't be trying to reverse-engineer a twenty-year-old SQL database.

And someone who has never administered Applied Epic should not suddenly become responsible for making technical Epic decisions simply because nobody else was available.

You do need to stay involved.

Nobody knows your business better than you do. There are mapping decisions and historical questions that only your agency can answer.

But there is a difference between providing the business knowledge and performing the conversion work.

At InsurCore, our job is to carry the technical workload.

We work with your source database, identify data-quality issues, restore and analyze the source environment, map and transform the information, prepare the data for Applied Epic, execute imports, reconcile the results, work through exceptions, and support validation.

Throughout the project, we bring findings back to the weekly meetings so your team can make informed business decisions without being buried in the underlying technical work.

And when an agency doesn't have the internal Epic administration experience necessary to manage the destination side of the project, we can fill that gap as well.

That is what we mean when we say end-to-end data conversion.

It isn't just moving records.

It's taking responsibility for the process required to get from the original backup to a converted environment that your agency can confidently begin using.

Final Thoughts

Every conversion is different.

We've worked with clean databases and messy ones, small books and enormous ones, modern SQL systems and technology that has been running inside agencies for decades.

There is no magic button that makes all of those systems identical.

But the process can still be predictable.

Get the right people involved. Make sure somebody knowledgeable owns the Epic side of the project. Secure the complete source data. Analyze before converting. Make mapping decisions deliberately. Test before production. Reconcile what you imported. Communicate the freeze plan. And treat go-live as the beginning of validation rather than the end of the project.

Most importantly, make sure everyone understands who is responsible for what.

Your agency should provide the business knowledge required to make good decisions.

Your implementation partners should help you configure and operate the destination environment.

And your conversion partner should do the heavy lifting required to actually move, cleanse, map, validate, and reconcile your data.

That's the model we've built InsurCore around.

Because the goal isn't simply to say the conversion completed.

The goal is to know that the data arrived where it belongs—and to be able to prove it.

Contact us to get started on your data conversion at 352-418-0123 or email [email protected].

Cheers,

Erik Jensen
Principal - InsurCore