HawkSoft to Applied Epic Conversion Guide

How to Convert HawkSoft Data to Applied Epic

What to prepare and how to verify the transfer • By Erik Jensen

A HawkSoft to Applied Epic conversion starts with a complete source export and an agreed definition of what needs to move. Clients and policies are part of that conversation, but so are the notes, documents, assignments, and historical references your employees need when they open an account. Those decisions determine the extraction, mapping, import preparation, and verification work that follows.

The question I would ask before setting a conversion date is whether everyone means the same thing when they say the data is moving. An agency may expect years of attachments and activity history. A project plan may only describe clients and policies. Both sides can think they have agreed on the conversion until somebody looks for an old document after the move.

That is preventable. Define the expected result while the source system is still available, confirm the export supports it, and test enough of the book to expose the problems before the final import. Here is how I would approach that work.

Confirm what your HawkSoft export actually contains

For the HawkSoft export structure described in our conversion service, the source consists of an agency SQLite database and multiple client database files. The physical attachments also need to be supplied when documents are included. Receiving a ZIP does not by itself confirm that the delivery is complete.

Start with an inventory of what was delivered and when it was produced. Confirm the expected files, identify duplicate copies, and check that the databases can be read. If the delivery differs from what the project expected, resolve that before treating it as the final source. Export structure and availability should be checked for the specific agency and version involved.

Keep the original delivery intact. Work from controlled copies and retain a record of the files used for each test. If the source changes between the sample conversion and the final delivery, your team should be able to explain what changed. Otherwise, a missing policy can become an argument about which backup somebody used instead of a problem you can trace.

Put the conversion scope in writing

A useful scope explains what users should find in Applied Epic, how much history is included, and which exceptions need approval. It should also explain how the project will handle information that cannot be placed into an equivalent destination field.

Clients, contacts, and policies deserve their own definitions. For example, does the project include inactive clients? How are duplicate contacts handled? Which policy terms and statuses are included? Are you bringing several acquired agencies into an existing environment where some clients are already present? These decisions affect matching and validation before an import file is built.

Treat documents and history with the same care. Agree on the attachment date range, document categories, and activity sources. Make a separate decision about accounting or commission information rather than assuming it follows the policy records. The approved destination method and available source data determine what is possible.

For information that needs to remain accessible as a summary, define the format and where it will appear. A summary activity can preserve useful context, but users need to understand that it has a different purpose from a populated structured field. That distinction belongs in the sample review, while there is still time to change the approach.

Resolve mapping decisions before importing the book

Mapping connects the values in HawkSoft with the values and relationships your Applied Epic environment expects. It includes more than column names. Your team needs approved decisions for account identification, carriers, users, policy statuses, lines of business, and organizational assignments where they apply.

The HawkSoft client number needs a traceable relationship to the Applied Epic lookup code. Retain that cross-reference throughout the conversion so a reviewer can move from the original account to the imported account without relying on a similar name.

An existing Epic environment adds another consideration: whether the source record represents a new account or something already present. Agree on the matching rules and how uncertain matches will be reviewed. A record that looks similar is a candidate for review; similarity alone should not authorize a merge.

We handle the technical extraction, cleanup, and transformation at InsurCore. The agency still needs to approve decisions that depend on business context. If two carrier descriptions point to different companies, or an old employee code needs a new assignment, those choices should be documented. Recurring conversion meetings are useful because they keep those decisions moving and give everyone a shared record of what was approved.

Check activity history for meaning and duplication

History is often the first thing an employee needs when a client calls. The conversion review should therefore look beyond whether an activity exists. Check that it belongs to the correct account, carries the appropriate date, and preserves the information needed to understand what happened.

Define how the project will handle duplicate entries and unusually long text. Removing exact duplicates can be appropriate, but the decision should be recorded. Similar descriptions on different dates may represent separate events. A cleanup rule that treats them as the same thing can remove legitimate history.

Review a few real examples from different parts of the agency’s work. A short phone note, a longer service discussion, and a record containing email content may expose different issues. Verify that useful text remains readable and that any transformation is consistent with the approved scope.

Verify the attachment files and their account relationships

In the HawkSoft export format we describe, physical attachments are matched to database records by attachment ID. A folder of files and a list of attachment records are two different things to reconcile. You need to confirm both the file and the destination relationship.

Use a representative sample that includes different document types and account relationships. Open the imported files in Applied Epic. Check whether the document is readable, belongs to the expected client or policy where applicable, and has a useful description. A successful upload message does not answer those questions.

An attachment that is absent from the source delivery needs a different resolution from one that failed during import. The first may require another export. The second may need correction and a rerun. Keep those issues separate so the project team knows what can be fixed by the conversion process and what requires additional source material.

Test records that are likely to expose problems

A sample conversion should help you learn something. Choose accounts with the kinds of complexity that exist in the book: several contacts, multiple policies, substantial history, unusual names, or many attachments. Include the records your service team would be most concerned about losing or misunderstanding.

Give reviewers specific checks rather than asking whether everything looks good. Ask them to compare selected source and destination records, open documents, review assignments, and identify anything they cannot locate. Record the result against each sample account so a correction can be retested.

Your internal conversion lead should know how to navigate and work in Applied Epic. That person needs to distinguish a conversion issue from a destination configuration question and help the team make informed decisions. If you do not have that capacity, agree on who will perform those reviews and how InsurCore will support the technical work.

Reconcile the results and explain the differences

Record counts are essential, but they need context. An imported client count may be lower because approved duplicates were merged. A history count may differ because the agency selected a date window. A document count may differ because files were missing from the export. None of those explanations should have to be reconstructed after delivery.

For each data category, account for what was in the source, what fell within the approved scope, what imported successfully, and what remains unresolved. Keep deliberate exclusions separate from failures. Where one source record becomes several destination records, document the transformation rather than forcing the totals to appear equal.

The remaining exception list should tell the team what needs a decision, what can be corrected, and what cannot be recovered from the supplied source. Define who approves the outstanding items. Completion should mean the agreed scope has been delivered and verified, with any accepted limitations documented.

Agree on how final changes will be captured

The agency will usually continue working while the conversion is being prepared. Identify the final export point and agree on how later changes will be tracked. New clients, policy changes, activities, and documents can all create differences between a tested backup and the records employees expect on the first day in Epic.

Do not assume every project supports the same incremental update method. The source export, destination tools, access, and project scope determine the options. Confirm the procedure with the implementation team, including who records changes and who verifies that they reached the destination.

Where InsurCore fits

InsurCore handles the data conversion work: assessing the source delivery, extracting and mapping the approved records, cleaning the data, preparing the import, and reconciling the result. Import execution and destination verification responsibilities are defined during scoping. We present findings, work through approved changes, and keep the technical work connected to the project’s decisions.

Training and rebuilding the agency’s operating workflows belong with the implementation specialists responsible for those areas. We can coordinate with that team while staying focused on the conversion. The agency gets clearer responsibilities and a practical way to confirm that the information it needs has moved.

If you are planning a HawkSoft move, start with the export and the information your team needs to retain. We can review the source, identify the gaps, and explain what the conversion will require before you commit to a final date.

Review our HawkSoft to Applied Epic conversion service

Explore Applied Epic data conversion services