Migrate from Aotal to Bullhorn ATS & CRM

Aotal Employee records map to Bullhorn Candidate records as the primary talent entity. Employee first name, last name, date of birth, contact details, address, employment status, and hire date transfer to corresponding Bullhorn Candidate fields. We use Candidate as the target because Bullhorn is an ATS-centric system where the employee record is created from a placement event; the candidate becomes the person record that persists through placement. Historical employee status changes (new hire, active, on leave, terminated) migrate as Candidate record updates with custom fields tracking employment state.

Aotal Department records require mapping based on whether they represent the agency's internal org structure or client organisations. Internal departments map to Bullhorn Corporate (ClientCorporation) records with a custom field department_type__c = 'internal' for reconciliation. Client organisations that Aotal manages as hiring entities map directly to Bullhorn ClientCorporation. We resolve the lookup relationship to ensure Candidate records can reference the correct corporate entity.

Aotal Role records (job titles, position descriptions, pay grades, FTE status) map to Bullhorn JobOrder as the recruiting representation, with role-specific fields stored in a Bullhorn Custom Object (role_profile__c) attached to the JobOrder. For agencies that use Aotal roles to track internal headcount planning rather than recruiting, the Custom Object attaches to Candidate or ClientCorporation. We confirm the role usage pattern during discovery.

Aotal performance review cycles with ratings, goals, and manager feedback have no native Bullhorn equivalent. We design a Bullhorn Custom Object (performance_review__c) with fields for review period (start_date__c, end_date__c), rating score (rating_value__c), reviewer name (reviewer__c, picker:user), goals, and free-text feedback. The Custom Object attaches to the Candidate record. Bullhorn Front Office Growth/Enterprise supports up to 10 Custom Objects with 55 fields each; we allocate one to performance data.

Aotal competency frameworks (skills, certifications, qualifications, licensing) map to a Bullhorn Custom Object (competency_profile__c) with up to 55 fields covering skill name, proficiency level, certification expiry, and issuing body. Bullhorn's Picker fields allow linking competencies to Candidate records. For agencies with licensing or compliance requirements (common in NZ healthcare, construction, and trades), we include expiry date fields with a note to configure Bullhorn reminders or an external compliance tool post-migration.

Aotal training completion records, course enrollments, and certification achievements map to a Bullhorn Custom Object (training_record__c) attached to the Candidate. Fields include course name, completion date, expiry date, training provider, and delivery method (online, in-person). Bullhorn ATS Growth does not include Custom Objects; we recommend Bullhorn ATS (2 Custom Objects) or Front Office Growth (10 Custom Objects) for this migration scope.

Aotal onboarding task lists and completion status for new hires map to a Bullhorn Custom Object (onboarding_checklist__c) attached to the Placement or Candidate record. Each checklist item migrates as a row with fields for task name, required/optional flag, due date, completion status, and assigned owner. Bullhorn's native Task object can supplement for simple task items; complex onboarding workflows with conditional paths require a documented rebuild plan.

Aotal leave management records (annual leave, sick leave, parental leave) have no direct Bullhorn equivalent. We map to a Bullhorn Custom Object (leave_record__c) attached to the Candidate with fields for leave type, start date, end date, status, and hours taken. Alternatively, for agencies that handle leave in a separate payroll or HRIS system, we flag leave records as out-of-scope for Bullhorn migration and recommend that the customer's payroll admin reconcile leave balances in the target HRIS.

Aotal job applications (candidate applied to a role) map to Bullhorn's Candidate linked to a JobOrder. When a candidate is placed in a role, we create a Bullhorn Placement record that captures the placement date, client, job order, start date, and pay rate. Aotal's application status maps to Bullhorn Opportunity or JobSubmission status values, and the status history migrates as notes or custom status fields on the Candidate.

Aotal emergency contact details stored on the Employee record map to a Bullhorn Custom Object (emergency_contact__c) attached to the Candidate. Bullhorn's Understanding Custom Objects documentation (kb.bullhorn.com) confirms that emergency contact information is a canonical use case for Bullhorn Custom Objects. Fields include contact name, relationship, phone number, and email address.

Binary documents stored in Aotal (contracts, signed agreements, certificates, CVs) migrate as Bullhorn ContentDocument records attached via ContentDocumentLink to the relevant Candidate, ClientCorporation, JobOrder, or Placement. Resume files migrate as Candidate resumes parsed by Bullhorn's native resume parsing on import. Contract and certificate files migrate as general ContentDocument attachments with a custom document_type__c field for classification.

Aotal employee records with manager assignments map to Bullhorn User records. We resolve by matching Aotal employee email to Bullhorn User email. Any Aotal employee without a matching Bullhorn User goes to a reconciliation queue for the customer's admin to provision the User before record import resumes. Manager reporting relationships are stored in a custom field manager_user__c (picker:user) on the User or Candidate record.