AMS360 to Applied Epic Conversion
An AMS360 to Applied Epic conversion moves an agency's clients, contacts, policies, lines of business, carriers, staff assignments, activity history, and attachments out of Vertafore AMS360's SQL Server database and document export, maps them to Applied Epic codes, and loads them through Applied Epic's import process, with every record reconciled.
The Source
What an AMS360 conversion starts from
AMS360 is a Vertafore product built on Microsoft SQL Server. Its core agency data sits in tables prefixed AFW_: customers, basic policy information, policy transactions, lines of business, companies, employees, policy personnel, claims, and the activity tables. Attachments are a second deliverable: the document records are in the database, while the files arrive as a separate document image export.
Because both halves are needed, intake confirms the database copy and the document export together. If you are still evaluating the move, a conversion readiness assessment checks the AMS360 backup and document export before a timeline is set.
Data Domains
What moves from AMS360
Actual scope is set per engagement. These are the AMS360 data domains we extract and map:
Clients
Customer records, with named insureds that AMS360 stores per policy.
Contacts
Gathered from several places: customer contacts, policy contacts, co-insureds, dependents, and mortgagees or lienholders.
Policies and transaction history
Basic policy information plus the policy transaction history behind each term.
Lines of business and coverages
Each line on each policy, with coverage and premium detail where in scope.
Carriers and brokers
The company master, including writing and issuing companies and NAIC codes where AMS360 holds them.
Employees, producers, and CSRs
Staff records and the producer, CSR, and broker assignments on each policy.
Activities, tasks, notes, and remarks
Four separate history sources in AMS360, combined into Applied Epic activities.
Attachments
Document records matched to the document image files exported alongside the database.
Claims
Claim records where included in the engagement scope.
Known Quirks
AMS360-specific challenges and how we handle them
Status codes describe endorsements, not whether a record is current
On many AMS360 tables a status flag records what changed at each endorsement (added, changed, deleted) rather than marking the live record. Reading it the obvious way pulls superseded or deleted rows into the conversion.
How we handle it: We select the current version of each record as the one with the latest effective date that is not marked deleted, and keep the rule documented so your team can check it.
GUID keys that are hard to trace
AMS360 identifies most records with long GUID keys, which are awkward to carry through spreadsheets and import files.
How we handle it: Each record gets a simple integer key for the conversion, with the original AMS360 GUID kept beside it, so any row in an output file can be traced back to its source record.
Policies carry multiple lines of business
A single AMS360 policy can hold several lines, and package business is flagged by policy type. Joining lines on the line identifier alone can collapse lines together and attach them to the wrong policy.
How we handle it: We keep one row per policy and line, separate package from monoline policies using the policy type, and stop the run if the line count does not match the source.
Writing company, issuing company, and brokers
The writing company on an AMS360 policy is often different from the issuing company, and brokers live in the same company master as carriers.
How we handle it: Both companies are carried through, brokers are separated by their company type, carrier names come from the company master (never from the client record), and NAIC codes are exported where AMS360 has them.
History spread across four places
Activity history sits in transactions, suspense items (tasks), notes, and remarks, each linked differently and authored by an employee code.
How we handle it: We combine all four into Applied Epic activities, resolve each author from the employee code, and link comments back to their parent entry so history is not lost in the join.
Contacts are scattered
There is no single contact list. People connected to an account appear as customer contacts, policy contacts, co-insureds, dependents, and mortgagees or lienholders.
How we handle it: We pull every source into one contact set with its own IDs, keeping the relationship type so your team can decide what belongs in Applied Epic.
Attachments live outside the database
Document records are in the database, but the files themselves come as a separate image export spread across numbered folders.
How we handle it: Each exported file is named by its AMS360 document ID, so we match files to document records one-to-one, then reconcile the inventory: matched, missing, orphaned, duplicated, and deleted, with a file-size cross-check.
The Process
How the AMS360 conversion runs
Every engagement follows our seven-stage Applied Epic conversion process. For AMS360 the work concentrates in four places:
- Intake: confirm how the AMS360 database copy and document image export will be produced and transferred, and which domains and date ranges are in scope.
- Extraction into a staging layer that keeps every source key, followed by integrity checks that halt the run on problems such as employee ID collisions, line-of-business mismatches, or unmatched attachments.
- OldNew mapping: your team confirms the Applied Epic value for each employee, carrier, broker, and line of business actually in use.
- File preparation in the Applied Epic Book of Business import templates, then import, exception resolution, reconciliation, and first-run verification.
For the full service scope, see Applied Epic data conversion services; for how the import files themselves are built and reconciled, see Applied Epic BOB import preparation.
Moving an AMS360 agency onto Applied Epic?
Tell us what you have from AMS360 and we will tell you what the conversion will require.
Deliverables
What you receive
Related
Converting more than one agency?
AMS360 agencies often arrive as part of an acquisition pipeline alongside agencies on other systems. Our agency acquisition data migration work treats each source system as a repeatable conversion. Another Vertafore system has its own page: QQCatalyst to Applied Epic conversion. Unfamiliar terms are defined in the Applied Epic conversion glossary.
FAQ
AMS360 Conversion Questions
Do you need access to our live AMS360 database or a backup?
We work from a copy of the AMS360 SQL Server database, not your live production system. During intake we confirm how that copy is produced and transferred, and whether the document image export for attachments comes with it.
Can you convert AMS360 attachments into Applied Epic?
Attachments can be in scope. AMS360 keeps the document records in the database and the files in a separate image export; we match each file to its document record by document ID and reconcile what matched, what is missing, and what is orphaned before anything is loaded.
How do you handle AMS360 producers, CSRs, and brokers?
AMS360 stores policy personnel with a type that distinguishes CSRs, producers, and brokers. We extract each assignment, list every code actually in use in the OldNew mapping, and your team confirms the Applied Epic employee or broker it should become.
Will our policy history and notes come across?
Activity history in AMS360 is split across transactions, tasks, notes, and remarks. We combine those sources into Applied Epic activities with their original author resolved; how much history to bring is a scope decision we make with you up front.
Is AMS360 data converted with a BOB import?
Output is prepared in the Applied Epic Book of Business import templates. Whether the engagement is a BOB import alone or a fuller conversion with multiple import phases is confirmed during scoping.
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.