Migrate from ZenApply to Bullhorn ATS & CRM

ZenApply Jobs (Positions) map to Bullhorn JobOrder records. We extract Job name, description, department, and status from the CSV export and load them into Bullhorn JobOrder via the REST API, setting the status field to reflect open/closed/paused. Bullhorn JobOrder includes additional fields (employment type, pay rate, overtime class, etc.) that ZenApply does not expose in its standard export; we create these as empty custom fields or flag them for the customer to populate post-migration. The CSV export does not include salary band data unless manually added during export preparation, so we flag salary range fields as requiring admin verification in Bullhorn.

ZenApply Applications link a Candidate to a Job and carry submission date, application status, and source attribution. In Bullhorn the equivalent is a JobSubmission record tied to both a Candidate entity and a JobOrder entity. We decompose the application relationship at migration time: the Candidate record is created first, the JobOrder is confirmed to exist, and the JobSubmission is inserted last so that both foreign-key lookups are satisfied. Application status values from ZenApply vary by customer-configured pipeline; we normalise these to a standard set (Applied, Screening, Interview, Offer, Hired, Rejected) and map any non-standard status values to custom JobSubmission custom field values for audit.

ZenApply Candidate records map directly to Bullhorn Candidate records. Standard fields (firstName, lastName, email, phone, address) migrate to Bullhorn Candidate fields by exact name match. The ZenApply custom profile fields (which vary per-customer and cannot be exported as a schema) are enumerated during the discovery phase and mapped to Bullhorn Candidate custom fields we pre-create in the destination schema. Any custom field that maps to a Bullhorn picklist or multi-select requires us to pre-create the picklist values during schema configuration. Candidate deduplication uses email as the primary key.

ZenApply video resume assets are hosted as URLs that may become invalid once the ZenApply account is deactivated. We download each video to temporary storage during the migration window, preserving original filename and MIME type, then re-upload to Bullhorn as a Candidate Attachment using Bullhorn's REST API file upload endpoint. The Bullhorn Candidate record's mediaURL or attached file is linked via the CandidateAttachments endpoint. This step extends the migration timeline by one to two days per 100 video assets. We validate that re-uploaded video URLs are accessible before declaring the media transfer phase complete.

ZenApply allows custom profile fields at the position or global level with no admin-visible schema export. We enumerate every active custom field during discovery by walking through each Job's application form and the Candidate profile editor with the customer. Each discovered custom field is pre-created in Bullhorn as a Candidate custom field with the matching edit type (text, drop-down, multi-select, date, numeric) before the candidate import phase. Custom field values migrate as data during the Candidate import. Fields missed during discovery will not appear in Bullhorn; our structured discovery questionnaire is designed to capture every active custom field before the mapping spec is written.

ZenApply Interview Scorecards are linked to Applications and Interviewers and contain template structures and individual ratings. We preserve the scorecard template structure as Bullhorn Note records (using the Note body for comments and reviewer feedback) and create Bullhorn Candidate custom fields to carry numeric ratings or rating categories. Reviewer names map to Bullhorn User records via email match. Any scorecard templates that exceed 55 custom fields per entity (Bullhorn's limit for a single Custom Object) require a split across multiple Custom Objects on the Candidate entity.

ZenApply User records (Admin, Hiring Manager, Recruiter) map to Bullhorn User records. We match by email address during migration. Any ZenApply role type that does not map directly to a Bullhorn role (e.g., custom ZenApply roles) is flagged for the customer's Bullhorn admin to assign appropriate Bullhorn permissions post-migration. Unrecognised or inactive ZenApply users are held in a reconciliation queue.

ZenApply stores resume files, cover letters, and portfolio attachments as hosted file URLs. We download each file to temporary storage during the migration window, preserving original filename and MIME type, then re-upload to Bullhorn as a Candidate Attachment via the Bullhorn REST API. The attachment's linkedCandidateId field points to the migrated Candidate record. Bullhorn applies its own virus scanning and file size limits during upload; files that exceed Bullhorn's limit are flagged for alternative storage (a customer-provided S3 bucket or Bullhorn's attached media store with manual relinking).

ZenApply application records include a source attribution field (e.g., job board, referral, career site). We map this to a Bullhorn Candidate custom field (candidateSource) that we pre-create as a picklist. If the source attribution was stored differently across different Jobs in ZenApply, we normalise during the transformation step and flag any source values that cannot be matched to the Bullhorn picklist for admin review.

ZenApply Jobs carry a department field. We map this to Bullhorn JobOrder's built-in department field if the customer uses Bullhorn's standard department taxonomy. For customers with non-standard department naming that does not align with Bullhorn's defaults, we create a JobOrder custom field (department__c) with picklist values pre-loaded from the ZenApply CSV export.

ZenApply Job status values (Open, Closed, Paused, Draft) map to Bullhorn JobOrder status values. We configure the Bullhorn JobOrder status field before migration to include any non-standard ZenApply status values as picklist entries, ensuring no status value is rejected during import.

If ZenApply tracks placements as a record type within Applications or as a separate entity (depending on the customer's configuration), we map them to Bullhorn Placement records, which link a Candidate to a JobOrder and include start date, end date, pay rate, bill rate, and markup fields. Bullhorn Placement is a first-class entity with its own API endpoints, and placement data often requires Client/Company records to exist first, which affects the dependency ordering of the migration load sequence.