Migrate from Avature to Recruit CRM & ATS

Avature Person records with candidate activity (applications, job associations, engagement history) map to Recruit CRM Candidate records. We enumerate all active custom fields on the Avature Person object before migration and map them to Recruit CRM custom fields, preserving the original field values. Person records without any candidate activity (pure employee records) require classification during discovery: we either migrate them as Candidates with an inactive status or flag them for the customer's admin to handle separately, since Recruit CRM is a recruitment ATS-CRM without a dedicated employee module.

Avature Person records that represent employees rather than candidates (no job applications, no engagement as a candidate) do not have a direct Recruit CRM equivalent because Recruit CRM does not have an employee module. We classify these records during migration scoping and migrate them as inactive Candidates with a custom field original_avature_type__c set to 'employee', preserving name, contact information, and any record table data as candidate notes or custom fields.

Avature Company records map directly to Recruit CRM Client records. Company name, industry, address, and custom fields migrate as Client fields. The Avature Person-to-Company linkage is preserved as the Candidate's assigned Client lookup in Recruit CRM. We resolve the Client record first so that the Candidate import satisfies the lookup dependency at insert time.

Avature Job records map to Recruit CRM Job records with status, department, location, and job description preserved. We map the Avature job status (Open, On Hold, Closed) to Recruit CRM's equivalent status values. The job-to-person associations (which Candidates have applied to which Jobs) migrate as Candidate Job Applications linking the two records.

Avature's customizable pipeline stages within Job workflows vary by implementation. We enumerate every distinct stage name, order, and associated Job template during discovery, then configure Recruit CRM's candidate pipeline stages to match. Stage names are preserved as a custom field avature_original_stage__c on the Candidate record for audit. Any automation triggers attached to Avature stages do not migrate and are documented separately.

Avature record tables attached to Person records (multi-row employment history, education, certifications) require flattening into normalized child records. We extract each record table as a separate extract, then map row data to Recruit CRM Candidate custom fields where field count allows, or to candidate notes formatted with section headers where custom field limits are exceeded. The parent-person-to-candidate lookup is resolved at migration time.

Avature hiring manager portal activities—interview feedback, ratings, notes submitted by hiring managers—map to Recruit CRM candidate activity log entries. We extract these as comment entries associated with the Candidate record with a timestamp preserved from the original Avature activity. Call, email, and meeting engagements from Avature's CRM layer map to the corresponding Recruit CRM activity types. The activity ordering is preserved by setting the timestamp to the original Avature creation date.

Avature Datasets store bulk reference data used by workflows and forms (industry lists, skill taxonomies, location hierarchies). Dataset structures vary by implementation. We extract dataset records during discovery, map them to Recruit CRM lookup lists or custom dropdown fields on the relevant object, and document any Dataset that has no direct Recruit CRM equivalent for the customer's admin to configure post-migration.

Avature user accounts (recruiters, hiring managers, admins) map to Recruit CRM User records. We resolve users by email address match. Any Avature user without a matching Recruit CRM account goes to a reconciliation queue for the customer's admin to provision before Candidate import begins, because OwnerId lookups on Candidate and Job records require valid User references.

Avature candidate tags and talent pool memberships map to Recruit CRM candidate labels or tags. Tags stored as multi-select properties flatten to comma-separated label strings in Recruit CRM. Talent pool membership does not have a direct equivalent in Recruit CRM; we map pool membership to a custom Candidate field avature_talent_pool__c or to a candidate list membership depending on the customer's preference during scoping.