QQCatalyst to Applied Epic Conversion
A QQCatalyst to Applied Epic conversion extracts customers, contacts, policies and their lines, carriers, staff assignments, notes, tasks, emails, and documents from the agency's QQCatalyst database, resolves QQCatalyst's overlapping IDs and single-CSR model into Applied Epic accounts and service roles, and reconciles every record.
The Source
What a QQCatalyst conversion starts from
Our QQCatalyst conversions run against the agency's QQCatalyst data in a SQL Server database. Customers are built from separate entity, people, and business tables; policies and quotes share a policy table with dozens of line-specific detail tables behind it; and documents, including their old versions, are stored in the database itself.
How the database copy is produced and transferred is confirmed at intake. A conversion readiness assessment can settle that, along with how much history and which documents are in scope.
Data Domains
What moves from QQCatalyst
Actual scope is set per engagement. These are the QQCatalyst data domains we extract and map:
Clients
Customers built from the underlying people and business records, with personal and commercial accounts told apart.
Contacts and addresses
Related contacts, main business contacts, phone and email details, and addresses.
Policies and lines
Policies with status and commission, and one row per policy line.
Coverage detail
Line-specific policy detail such as auto, home, commercial auto, workers compensation, umbrella, general liability, property, inland marine, and professional liability.
Carriers and billing companies
Carriers with NAIC codes and parent companies, plus the MGA or billing company on each policy.
Employees, producers, and CSRs
Office employees, the producer and CSR on each customer, and policy producers.
Activities, notes, and tasks
Notes and note history, text messages, claim entries, tasks, remarks, and emails.
Attachments
Documents linked to customers and, where applicable, to policies.
Known Quirks
QQCatalyst-specific challenges and how we handle them
One CSR and one producer per client, several service roles in Applied Epic
QQCatalyst records a single CSR and a single producer on each customer. Applied Epic accounts and policies can carry several service roles.
How we handle it: We export service roles as numbered role columns for commercial clients, individual clients, packaged policies, and non-packaged policies, each of which can be switched on or off. The CSR is ranked first; other producers follow by how much of the account they appear on, and duplicate roles are removed.
Client IDs and policy IDs overlap
In QQCatalyst the same number can be both a customer ID and a policy ID, which makes it easy to attach a client document to an unrelated policy or route a note to the wrong client.
How we handle it: Client-level documents have false policy links removed, and notes are routed by their subtype rather than by ID alone.
Policy status is spread across flags
Policy status is not a single field. Cancelled, voided, non-renewed, pending, and issued are separate flags, and deleted rows are still present.
How we handle it: We derive one policy status from the flags, drop deleted rows, and put premium on the primary line only, so policies with more than one line are not double-counted.
Contacts repeat on every policy version
Drivers, co-applicants, additional named insureds, and additional interests are stored again on every renewal or quote, and the named insured appears as their own "Self" contact.
How we handle it: We de-duplicate parties by account and name, keep the copy that has an email, phone, or address, and leave out self-contacts.
Documents are stored inside the database, with old versions
QQCatalyst keeps documents in the database alongside superseded versions, and one document can be linked to many policies.
How we handle it: We separate active documents from dead versions, link each to its customer and policies, and can exclude hidden documents so attachment counts match what your staff see in QQCatalyst.
Email bodies are not plain text
QQCatalyst does not store email bodies as readable text; they are encoded message files.
How we handle it: Email bodies are parsed in a separate step so the text can travel with the activity into Applied Epic.
The Process
How the QQCatalyst conversion runs
Every engagement follows our seven-stage Applied Epic conversion process. For QQCatalyst the work concentrates in four places:
- A source adapter reads the QQCatalyst tables into a consistent working structure, so the same conversion logic applies to each QQCatalyst agency.
- Validation in six phases: lookup codes, personal and commercial profiles, contacts, policies, attachment records, and the attachment file inventory.
- Mapping workbooks your team completes, including customer sources, service roles, carriers, and lines of business; blank cells never overwrite values already approved.
- Output in Applied Epic Book of Business import templates, checked against Applied validation workbooks, followed by 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 QQCatalyst agency onto Applied Epic?
Tell us what you have from QQCatalyst and we will tell you what the conversion will require.
Deliverables
What you receive
Related
Converting more than one agency?
QQCatalyst 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. Another Vertafore system has its own page: AMS360 to Applied Epic conversion. Terms are defined in the Applied Epic conversion glossary.
FAQ
QQCatalyst Conversion Questions
How do you handle service roles when QQCatalyst only has one CSR and one producer?
We carry the CSR and producer across as service roles, ranked with the CSR first, and add other producers who appear on the account by how much of it they handle. Your team confirms the Applied Epic employee and role for each before files are built.
Can you convert QQCatalyst attachments into Applied Epic?
Attachments can be in scope. QQCatalyst keeps documents and their old versions in the database; we separate the active documents, link each to its customer and policies, and reconcile counts against what your staff see in QQCatalyst.
Do QQCatalyst emails come across with their text?
Email bodies in QQCatalyst are stored as encoded message files rather than text. They are parsed in a separate step so the readable text can be included with the activity.
What happens to customer source?
Each QQCatalyst customer source is listed in a mapping sheet for your team to translate into the Applied Epic value you want, and the approved mapping is applied to every client.
Is there anything QQCatalyst does not have that Applied Epic expects?
Yes. QQCatalyst has no direct equivalent for some Applied Epic structures, such as claim contacts or certificate holder details. Those are documented as empty rather than filled with guessed values.
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.