Plain-language definitions of the terms agencies run into during an Applied Epic data conversion, from source backups and OldNew mapping to BOB import files, reconciliation reports, and first-run verification.
Terms
Conversion projects bring together agency operations, Applied Systems implementation teams, and database work, and each group uses its own vocabulary. These definitions describe how the terms are used on InsurCore engagements. For the services behind them, see our Applied Epic data conversion services.
Applied Epic's Book of Business Import Utility is a structured, file-based process for bringing client, policy, and related records into Applied Epic. The import files must match specific column names, column ordering, tab names, and formatting requirements, and large books are often divided into several files to fit import constraints. A BOB import is one pathway into Applied Epic, not the whole conversion. See Applied Epic BOB import services.
A mapping approach that pairs each code or value used in the old system with its Applied Epic equivalent: employees and producers, carriers and companies, lines of business, client lookup codes, and similar lists. In practice the OldNew is a multi-tab workbook extracted from the source data, listing every value actually in use so the agency can confirm or assign the Applied Epic value for each before records are transformed.
A BOB import uses the Book of Business Import Utility for structured file-based imports. OldNew mapping translates source codes and structures to Applied Epic equivalents. A full conversion is the broader engagement around them: backup restoration, extraction, mapping, cleanup, file preparation, import execution, reconciliation, and first-run verification across multiple data domains and coordinated import phases. Which pathway applies depends on the source system, the backup, and the scope. See how the pathways compare.
The copy of the old agency management system data that the conversion is built from. For SQL Server-based systems this is usually a .bak database backup file that has to be restored before anything can be extracted; other systems provide a data export, a set of database files, or a folder of spreadsheets instead. Restoration requirements (database version, credentials, file completeness) are confirmed during intake so they do not surface mid-project.
The documented decisions about where each source field and value lands in Applied Epic: which column becomes the client name, how a source policy type translates to an Applied Epic line of business, which source user becomes which Applied Epic employee. Mapping is approved by the agency; records that do not map cleanly are documented as exceptions rather than force-fitted.
The coverage categories a policy belongs to, such as personal auto, homeowners, commercial package, or workers compensation. Every source system names and codes these differently, and a single source policy type can need to be split or combined to match the line of business codes configured in the target Applied Epic environment.
The codes that identify which employees are responsible for an account or policy: producers (the people credited with selling it) and servicers or account representatives (the people who service it). Source systems store these as user IDs, initials, or names; the conversion maps each one to an Applied Epic employee code, and departed employees need an explicit decision about where their book is assigned.
The history of work recorded against a client or policy: notes, logged calls and emails, tasks, and follow-ups. Source systems often keep these in several separate tables. A conversion has to combine them, attach each one to the right account (and policy, where known), preserve the original dates and author, and respect any date window the agency chooses for how much history to bring.
Documents stored against clients and policies in the old system: applications, declarations pages, correspondence, scanned files. Converting them means inventorying the actual files, matching each one back to the correct client (and policy where possible) using the source system's own references, and reporting files that could not be matched instead of quietly leaving them behind.
IVANS is an insurance industry data exchange network that many carriers use to send policy and related transaction data electronically to agency management systems; the electronic feed into the agency system is commonly called download. Download setup in a new Applied Epic environment is generally configured separately from the historical data conversion, so agencies should confirm with their implementation team how and when it will be set up around cutover.
The point at which the agency stops working in the old system and starts working in Applied Epic. The source backup or export is usually taken close to cutover so the converted data is current; anything entered in the old system after that snapshot has to be identified and handled separately.
A record that compares what went in against what came out: source counts, output counts, import successes, failures, intentional exclusions, and exceptions, broken out by data domain. It is how an agency confirms that every record was converted, excluded on purpose, or explained.
The list of records that could not be converted as-is, with the reason and the decision taken for each: values that did not match an Applied Epic code list, duplicate clients or contacts, records that failed the import, and records excluded from scope. Actionable exceptions are corrected and included in a rerun file; the rest are documented rather than silently dropped.
The review of the first converted data in Applied Epic with the agency and its implementation stakeholders: spot-checking accounts, policies, and history against the source, confirming counts against the reconciliation report, and catching mapping problems before the remaining data is finalized. See the Applied Epic conversion process.
By Source System
The same terms play out differently depending on what you are converting from: a SQL Server backup, a database file export, or a set of spreadsheets. Our source-system pages describe what that looks like in practice.
Not sure where your data stands? A conversion readiness assessment reviews your backup, data quality, and scope before a timeline is set. More answers are in the Applied Epic conversion FAQ.
FAQ
A BOB import is a structured file-based import through the Book of Business Import Utility. A full conversion is the broader engagement around it: restoring the source backup, extracting and mapping data, preparing the import files, running the import, reconciling results, and supporting first-run verification.
No. The OldNew is the mapping layer that pairs source codes and values with their Applied Epic equivalents so the agency can confirm them. The import files are produced afterward, using those approved mappings.
Generally: confirmation of your source system, an understanding of the available backup or export, the data domains you want converted, your target Applied Epic environment, and your timeline.
The conversion process page walks through all seven stages, and the conversion FAQ answers the questions we hear most from acquisition and implementation teams.
More questions? Read the full Applied Epic Conversion FAQ.
Whether you need overflow capacity for one acquisition or a repeatable conversion partner across an active pipeline, we'll help you define the scope, inspect the source data, and build a practical path into Applied Epic.
Built for insurance agencies, brokerages, aggregators, and acquisition teams that need experienced conversion capacity without building another internal department.