Migrate from ZippyApp to Bullhorn ATS & CRM

ZippyApp Job Seeker records (name, email, phone, address, work history) map to Bullhorn Candidate. The Job Seeker's application history across multiple employers is preserved by linking each JobSubmission record (see below) to the Candidate. We perform an email-dedupe check at import time: if a Candidate with the same email already exists in Bullhorn, we attach the new application to the existing record rather than creating a duplicate. The original ZippyApp source is stored in a custom text field zippy_source__c for audit.

ZippyApp employer accounts (company profile, branding details, hiring team members) map to Bullhorn ClientCorporation. Industry vertical from the employer profile maps to the ClientCorporation industry field. If the employer operates multiple brands or locations under one account, we create one ClientCorporation per brand and link them via the parentId relationship to preserve the hierarchy. The employer account ID from ZippyApp is stored in a custom field zippy_employer_id__c on the ClientCorporation for reconciliation.

ZippyApp Positions (title, description, location, employment type, QR code reference) map to Bullhorn JobOrder. The Position title maps to JobOrder title; description maps to description; location maps to address or city fields. The ZippyApp QR code reference is stored in a custom text field zippy_qr_code__c on the JobOrder for reference. Employment type (full-time, part-time, seasonal) maps to the JobOrder employmentType field. JobOrder status is set to 'Open' for any Position with status 'Active' in ZippyApp.

ZippyApp Applications link a Job Seeker to a Position with a status field (submitted, reviewed, dispositioned). We map these to Bullhorn JobSubmission, which links Candidate and JobOrder with its own status field. The original ZippyApp application status is preserved in a custom field zippy_application_status__c on the JobSubmission for audit. If the customer requires employer-specific interview notes, offer terms, or onboarding flags that cannot fit in JobSubmission standard fields, we migrate those to a Custom Object (see below) linked to the JobSubmission.

ZippyApp stores no persistent engagement history per application, but if the employer has added internal notes or status-change timestamps within the ZippyApp inbox, we migrate these as a Bullhorn Custom Object linked to the JobSubmission. Bullhorn Custom Objects must be requested via Bullhorn Support ticket before migration begins. We file this request during the schema design phase so the Custom Object is provisioned and available when data import starts. The Custom Object name and field schema are defined during scoping based on what internal notes the customer confirms exist in ZippyApp.

ZippyApp resume files (PDF or DOCX attachments to Job Seeker records) are extracted as binary blobs and uploaded to Bullhorn as CandidateResume file records linked to the Candidate. Bullhorn parses the resume to populate candidate skills, work history, and education fields automatically. We store the original file name and ZippyApp upload timestamp in custom fields on the CandidateResume record. If the resume is a DOCX with embedded formatting that does not parse cleanly, we fall back to attaching it as a ContentDocument with a manual parse flag.

ZippyApp cover letters are optional file attachments per application. We attach them to the corresponding Bullhorn Candidate or JobSubmission Custom Object as ContentDocument records via ContentDocumentLink, with the document title set to 'Cover Letter - [Position Title]'. We flag in the migration report whether a cover letter was present for each application so the recruiter sees it at a glance without opening the file.

Push notifications and email alerts generated by ZippyApp during the hiring workflow are transient communication events stored by the notification service, not as persistent records in ZippyApp's database. We do not migrate them because they are not retrievable as structured data and have no Bullhorn equivalent that preserves the same delivery context.

Employer logos, brand colors, and QR-code graphics tied to ZippyApp employer accounts are media assets that do not map cleanly to any standard Bullhorn object. Bullhorn supports employer branding through its Career Portal configuration and JobOrder branding fields, which the customer's admin rebuilds post-migration based on their brand guidelines.

ZippyApp employer accounts contain named hiring team members who may have user-level roles. We map these to Bullhorn User records by matching email address. If a ZippyApp user has no corresponding Bullhorn User at migration time, they are placed in a reconciliation queue and the customer's Bullhorn admin provisions the User before the relevant records are assigned. OwnerId references on ClientCorporation and JobOrder records are resolved at this stage.

ZippyApp does not track candidate sourcing attribution as a first-class field. If the employer used QR codes tied to specific locations or campaigns, we capture this as a custom field zippy_source_channel__c on JobOrder. Bullhorn's standard source tracking fields (source, referredBy) are available on JobOrder for the customer's admin to populate if they implement source attribution post-migration.

ZippyApp application statuses (submitted, reviewed, dispositioned, archived by accidental UI action) do not map directly to Bullhorn's JobSubmission status values. We define a status mapping during scoping: submitted maps to 'New', reviewed maps to 'Interview', dispositioned maps to 'Rejected' or 'Offer Extended' based on employer intent, and any archived records are flagged with a custom status value pending admin review. The mapping is validated in sandbox before production migration.