Migrate from Zimyo to Bullhorn ATS & CRM

Zimyo Candidates from the Talent Acquisition module map to Bullhorn Candidate records. We map first name, last name, email, phone, current employer, current designation, resume/CV blob, source channel, and application status. Candidate ID in Zimyo is preserved in a custom field zimyo_candidate_id__c for cross-reference. Any Zimyo candidate rating or scoring properties map to Bullhorn custom numeric fields that the customer's Bullhorn admin configures before migration.

Zimyo Job Postings map to Bullhorn Job records. We map job title, job description, employment type, location, department, required experience, salary range, and status (open, closed, draft). The Bullhorn Job object requires an associated Client Corporation (Company) as a parent; we resolve this by creating or matching a Bullhorn Corporation record during the Job import phase.

Zimyo Applications represent the join between a Candidate and a Job Posting. We decompose each Application into a Bullhorn Candidate record linked to a Bullhorn Job record via the JobOrderCandidate association object. Application stage (applied, screening, interview, offer, hired, rejected) maps to the Bullhorn Candidate Job Audit ( candidacyStatus ) field on the association record. Any application notes or feedback from recruiters map to Bullhorn Note records attached to the CandidateJobOrder.

Zimyo interview schedules map to Bullhorn Event records or Task records depending on whether the customer's Bullhorn instance uses the calendar Event model or task-based interview tracking. Interview attendees, scheduled time, interview type (phone, video, in-person), and interviewer assignments map to Bullhorn Event with EventRelation records linking the Candidate, Job, and assigned User (interviewer). We validate timezone consistency between Zimyo's stored time and the Bullhorn org's configured timezone.

Zimyo offer letters are document blobs that map to Bullhorn Note records with the offer letter file attached via ContentDocumentLink. The offer letter body text migrates as a Note body; the PDF attachment migrates as a ContentVersion blob with original filename preserved. Offer terms (salary, start date, position) stored as structured fields in Zimyo map to Bullhorn custom fields on the Candidate record if configured, or to a Note for unstructured review.

Zimyo Employees who are also candidates in a hiring pipeline require a decision during scoping: whether they should migrate as Bullhorn Candidates (if still in active recruiting workflow) or as Bullhorn Contacts (if representing client companies or customer contacts). We apply a customer-defined rule based on employment status and pipeline involvement. Basic employee contact details (name, email, phone, department, designation) map to Bullhorn Contact or Candidate standard fields. Payroll and compensation fields on the Employee record have no Bullhorn equivalent and are excluded from the ATS migration scope.

Zimyo Organization Structure (departments, cost centers, locations, reporting hierarchies) maps to Bullhorn Corporation records for client organizations or to custom Bullhorn fields for internal department tracking. If the migration scope includes both ATS data and some basic employee directory data, department and location fields map to Bullhorn custom picklist fields. We align department codes and location identifiers during schema discovery and apply them consistently across both Candidate and Job records.

Zimyo organization-specific custom fields on Candidates, Jobs, and Applications map to Bullhorn custom fields on the corresponding Bullhorn entity. Bullhorn supports custom text, number, date, picklist, and boolean fields via Admin > Field Mappings. We discover the full custom field schema during scoping, map field types to compatible Bullhorn field types, and pre-create custom fields in the Bullhorn sandbox before production migration. Any custom fields with lookup relationships to other Zimyo objects require a corresponding Bullhorn lookup field with parent-record resolution at migration time.

Candidate documents in Zimyo (resume/CV, ID proofs, certifications) map to Bullhorn ContentDocument and ContentVersion records linked to the Candidate via ContentDocumentLink. We preserve original filenames, file type, upload timestamp, and file integrity checksums. File size limits and blob handling follow Bullhorn's ContentVersion size constraints. Any document without an associated Candidate in Bullhorn is held in a reconciliation queue.

Zimyo Payroll Runs (earnings, deductions, tax withholdings, net pay) have no Bullhorn equivalent. Bullhorn is an ATS and does not store payroll data. We extract a full payroll history export from Zimyo during the migration window, validate totals against Zimyo reconciliation reports, and deliver the export as a structured CSV and PDF archive to the customer for their payroll team or new payroll platform to ingest. This is out-of-scope ATS migration work documented as a parallel deliverable.

Zimyo Clock-in/Clock-out timestamps, overtime calculations, and shift mappings have no Bullhorn equivalent. Bullhorn's data model does not include attendance or time tracking. We extract attendance logs as a dated CSV export from Zimyo and deliver it to the customer for import into a dedicated timekeeping system if needed. This is documented as out-of-scope ATS migration work.

Zimyo Leave types, entitlement balances, accrual rules, carry-forward policies, and leave approval history have no Bullhorn equivalent. Leave management is a Zimyo HCM module not represented in Bullhorn's ATS model. We extract leave balance reports and carry-forward records from Zimyo as a structured export and deliver them to the customer for archiving or import into a parallel leave management system. This is documented as an out-of-scope deliverable separate from the ATS migration.