Migrate from Avature to Bullhorn ATS & CRM

Avature Person records (both candidate and employee subtypes) map to Bullhorn Candidate. The personType property on Avature determines whether the record is a Candidate or a ClientContact in Bullhorn—candidates map to Candidate with isDeleted=false and type='Candidate', while Avature employees who are client-side contacts may map to ClientContact depending on the company's relationship model. We preserve the Avature personType as a custom field (avature_person_type__c) on the Bullhorn Candidate for audit. Name, email, phone, and address fields map to their Bullhorn equivalents; custom fields migrate via Bullhorn Support-provisioned custom fields.

Avature Company records map to Bullhorn ClientCorporation. Company name becomes corporationName, and the Avature company website maps to the webSite field used as the dedupe key during import. We preserve company-industry associations and any company-specific notes as ClientCorporation custom fields. ClientCorporation must be created before any ClientContact or Candidate import that references it, to satisfy the clientCorporationId lookup.

Avature Job records map to Bullhorn JobOrder. The Avature jobStatus maps to Bullhorn status (Open, Pending, Closed), employmentType maps directly, and branchOfficeId maps to the relevant Bullhorn ownership. We map Avature department and location fields to JobOrder's customizable branch and location fields. Job descriptions migrate as a long-text field; compensation details migrate to salary or payRate fields depending on the Avature field's unit type.

Avature Person-Job linkages (candidates applied or submitted to a job) map to Bullhorn JobSubmission. We preserve the Avature submission date, current stage, and assigned recruiter from the Person record's job-workflow association. The JobSubmission record links the Candidate (from Person) to the JobOrder (from Avature Job) and records the user's assignment and submission source.

Avature candidate tags and talent pool memberships map to Bullhorn Candidate tags. Tags stored as multi-checkbox properties migrate as flat label entries in Bullhorn. Talent pool membership in Avature—used to group high-value candidates into named pipelines—may require conversion to Bullhorn talent pools or static Candidate lists depending on how the pools are used in the destination workflow. The customer chooses the pool-to-list strategy during scoping.

Avature hiring manager portal notes, ratings, and interview feedback submitted through the portal are stored as activity records on the Person. We extract these as Bullhorn Note records linked via ContentDocumentLink to the Candidate and, where applicable, the related JobSubmission. The original portal submission date migrates as the Note's dateAdded, preserving the hiring manager's feedback timeline in the Candidate record.

Avature multi-row record tables attached to Person records (employment history, education, certifications, skills) flatten into normalized child records. Each record-table type maps to a Bullhorn custom object (customObject1 through customObject10 depending on availability in the destination org) linked to the Candidate via a lookup. We require Bullhorn Support to provision each custom object before migration and then load the flattened rows with the parent Candidate ID resolved at migration time.

Avature unlimited custom fields on Person map to Bullhorn Candidate custom fields. Bullhorn Support must initially create each custom field via a support ticket before the migration loads data into them. We align the Avature internal field name to the Bullhorn field name during discovery and flag any field-type mismatches (Avature free-text vs Bullhorn picklist, for example) for the customer's Bullhorn admin to resolve before migration.

Avature Company custom fields map to Bullhorn ClientCorporation custom fields. Same setup pattern as Person custom fields—Bullhorn Support provisions each custom field first, then we load values via the REST API. We flag any Avature company custom fields that store candidate-relevant data (source tracking, client tier ratings) and discuss with the customer whether those should migrate to Candidate custom fields instead of ClientCorporation custom fields.

Avature Job templates define reusable requisition blueprints including fields, workflow steps, and approval chains. Template logic does not migrate as executable configuration because Bullhorn uses a different workflow model. We document each Avature Job template's field structure and recommended Bullhorn JobOrder field defaults, providing a written template mapping for the customer's Bullhorn admin to apply when creating new JobOrders post-migration.

Avature Datasets store bulk reference data used by workflows and forms. Dataset structures vary by implementation—they may contain industry lists, skill taxonomies, certification types, or client-specific rate cards. We extract Dataset records and evaluate whether each Dataset maps to a Bullhorn custom object, a static Candidate or ClientCorporation picklist, or an external reference document delivered alongside migration. Datasets with complex relationships to Avature Person or Job records may require custom mapping logic.

Avature workflow definitions (requisition workflows, onboarding flows, internal mobility pipelines) do not migrate as code. Bullhorn uses a different workflow engine with different trigger and action models. We deliver a written inventory of every active Avature workflow, capturing its trigger conditions, stage sequence, conditional logic branches, and assigned actions, with a Bullhorn workflow configuration recommendation per workflow. The customer's Bullhorn admin or a Bullhorn partner rebuilds the workflows post-migration.

Avature user accounts (recruiters, hiring managers, admins) map to Bullhorn User records. We resolve users by email address match. Any Avature user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Role-based permissions from Avature map as Bullhorn permission sets and public group assignments, though Bullhorn's role model may require manual adjustment for fine-grained Avature permissions.

Avature file attachments referenced by URL migrate cleanly to Bullhorn as ContentDocument records linked via ContentDocumentLink to the parent Candidate, ClientCorporation, or JobOrder. URL-based attachments extract and re-upload to Bullhorn's document storage. Base64-encoded attachments from Avature require decoding before upload to Bullhorn. We flag any attachment larger than 25 MB for chunked upload handling.