Applied TAM to Applied Epic Conversion
An Applied TAM to Applied Epic conversion extracts the dBase files in a TAM backup into SQL Server, verifies every row count, decodes TAM's keys, lettered dates, and operator codes, maps clients, policies, history, attachments, and claims to Applied Epic, and prepares reconciled import files.
The Source
What an Applied TAM conversion starts from
Applied TAM keeps its data in dBase (.DBF) files rather than a SQL Server database. A TAM backup holds a TAM folder with clients, policies, activities, claims, accounting, and the attachment index, and an APPS folder with rating and ACORD data. A handful of TAM files are encrypted and are identified up front rather than discovered mid-project.
The first deliverable is a faithful SQL Server copy of those files that can be checked row for row. A conversion readiness assessment can confirm the backup is complete before a timeline is set.
Data Domains
What moves from Applied TAM
Actual scope is set per engagement. These are the TAM data domains we extract and map:
Clients and prospects
The name and address master shared by every entity type, with prospects kept distinct from clients.
Contacts
People attached to each account, with phone numbers and email addresses.
Policies and policy history
Policies, their line of business and package type, and the policy history behind them.
Carriers
Carrier codes on each policy, resolved against the same master file as clients.
Employees, producers, and CSRs
Operator codes and the producer and CSR on each policy, resolved to named employees.
Activities and notes
The activity log, extended activity notes, and client notes.
Attachments
The attachment index, matched to the attachment files in the backup.
Claims
Claims, with claim notes and payments where they exist and are in scope.
Known Quirks
Applied TAM-specific challenges and how we handle them
The backup is a set of dBase files, not a database
An Applied TAM backup unpacks into hundreds of dBase (.DBF) files across a TAM folder and an optional APPS folder. There is no SQL backup to restore.
How we handle it: We extract every file into SQL Server as a table with the same name, columns, and row count, decode text with TAM's Windows character set, keep soft-deleted rows flagged rather than lost, and record each row's source file and position. A parity check compares SQL row counts with the row counts in each file's header; any difference stops the conversion.
One master file holds every kind of entity
In TAM a single name and address file holds clients, carriers, and other entities, and related records link to it through a short key-and-record pair. The client file is an overlay, not the customer master.
How we handle it: We build accounts from the shared master, keep client and prospect records distinct (the client record wins when both exist), and exclude template and artifact rows that are not real accounts.
Dates with a lettered decade
TAM writes many dates with a letter for the decade (A for the 2000s, B for the 2010s, C for the 2020s) in several layouts, and some date-looking fields hold term or rating text instead.
How we handle it: Dates are decoded by a dedicated routine that understands each layout, and fields that are not really dates are left as text rather than forced into a date.
History and claims are keyed to the client, not the policy
Policy history and claim records carry a key that identifies the client, not a specific policy, so the policy has to be worked out.
How we handle it: We resolve the policy by policy number within the client, falling back to the term date, and report claims whose policy cannot be identified with confidence instead of guessing.
Operator codes are not employee names
TAM identifies staff by short alphabetic operator codes, and some code fields contain values that are not operators at all.
How we handle it: Only genuine operator codes are kept, full names are decoded from TAM's terminal records, and producers and CSRs are resolved directly from the policy's codes where the history does not resolve them. Raw TAM codes are never used as Applied Epic employee lookup codes; your team maps each one.
Attachment files are named by sequence number
The files on disk are named by a base-36 sequence number and file type rather than by client, and the attachment index has rows that look identical.
How we handle it: We use the sequence number as the matching key, break ties with each row's original position, link an attachment to its policy where the keys line up, and attach it at account level otherwise.
Personal or commercial?
TAM does not label accounts as personal or commercial in a form Applied Epic can use directly.
How we handle it: Account type follows the format of the TAM record key, cross-checked against Applied-provided extract files when the agency has them, which take priority.
The Process
How the Applied TAM conversion runs
Every engagement follows our seven-stage Applied Epic conversion process. For Applied TAM the work concentrates in four places:
- Extraction of the TAM dBase files into SQL Server, with an extraction log and a zero-difference row-count parity check before anything else runs.
- A required-tables check, then extraction and OldNew mapping of clients, policies, employees, carriers, and lines of business for your team to confirm.
- Phased validation of data quality, profiles, contacts, policies, attachments, name matching, and data-quality flags, followed by post-run count checks.
- Output in Applied Epic Book of Business import templates for clients, policies, contacts, activities, and attachments, then import, exception resolution, and reconciliation.
For the full service scope, see Applied Epic data conversion services; for how import files are built, run, and reconciled, see Applied Epic BOB import preparation.
Moving a TAM agency onto Applied Epic?
Tell us what you have from TAM and we will tell you what the conversion will require.
Deliverables
What you receive
Related
Converting more than one agency?
TAM agencies are often one source among several in an acquisition pipeline. Our agency acquisition data migration work treats each source system as a repeatable conversion. Applied Systems' EZLynx has its own page: EZLynx to Applied Epic conversion. Terms are defined in the Applied Epic conversion glossary.
FAQ
Applied TAM Conversion Questions
What do we need to send from Applied TAM?
The TAM backup, unpacked or as delivered, including the TAM data folder and, where rating or ACORD data matters, the APPS folder, plus the attachment files if attachments are in scope. We confirm completeness with a file-by-file row-count check after extraction.
Can you convert Applied TAM attachments into Applied Epic?
Attachments can be in scope. TAM names attachment files by sequence number; we match each file to the attachment index by that number, link it to the policy where the keys line up, and attach it at account level otherwise.
Will TAM operator codes become our Applied Epic employee codes?
No. TAM operator codes are decoded to employee names and listed for your team to map to Applied Epic employees. The raw TAM code is never used as the Applied Epic lookup code.
Is a move from Applied TAM to Applied Epic simpler because both are Applied products?
The data still has to be converted. TAM stores it in dBase files with its own keys, date formats, and codes, so it goes through the same extraction, mapping, validation, and reconciliation as any other source system.
More questions? Read the full Applied Epic Conversion FAQ.
Bring Us the Backup. We Will Help Carry the Conversion Across the Finish Line.
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.