Migrate from ApplicantStack to Bullhorn ATS & CRM

ApplicantStack Positions map to Bullhorn JobOrder records. Job title, description, status (Open/Closed), and opening count transfer directly. Bullhorn JobOrder also capturesClientCorporation (the staffing firm's client account), which ApplicantStack does not model; we create a placeholder ClientCorporation record during migration or map to an existing Bullhorn client if the customer has already onboarded their account structure.

ApplicantStack Candidate records (name, email, phone, application date, source, status, resume file) map to Bullhorn Candidate. We run deduplication during transformation by email address, normalized phone number, and name string to flag likely duplicates for customer review before final import. Resume files migrate as Candidate document attachments. The applicant's original source field maps to Bullhorn's candidateSource field. Application date migrates as a date field; Bullhorn does not preserve a full application timeline audit in the standard Candidate object, so stage-history records migrate separately.

ApplicantStack's configurable pipeline stages (Applied, Screening, Interview, Offer, Hired, Rejected) map to Bullhorn JobSubmission records tied to a JobOrder. Bullhorn's pipeline is controlled by the JobOrder's workflow, not a separate pipeline object. We export the full stage history per candidate and replay it as a sequence of JobSubmission status changes with timestamps, preserving the candidate's progression through the hiring process. Closed dates and disposition reasons map to the JobSubmission record.

ApplicantStack Custom Questionnaires store field-value pairs tied to the candidate record. We map these to Bullhorn Candidate custom fields (up to the Bullhorn edition limit) or to a Bullhorn Custom Object if the questionnaire data is structured (multiple sections, repeated entries). The decision between custom fields and a Custom Object is made during scoping based on data complexity. Bullhorn Custom Objects require pre-provisioning via the Custom Object Setup Sheet; we create these before candidate import. Each field-value pair migrates with its original field label preserved as the Bullhorn field display name.

ApplicantStack user roles (Administrator, Recruiter, Hiring Manager) map to Bullhorn User records. We match users by email address. Bullhorn User records require provisioning by the customer's Bullhorn admin before migration; we provide a user reconciliation report listing every ApplicantStack user with their intended Bullhorn role assignment so the admin can provision matching accounts in advance. Any user without a Bullhorn account created before migration holds the corresponding records in a reconciliation queue.

ApplicantStack candidate tags migrate as Bullhorn tags on the Candidate record. Bullhorn supports free-text tagging; we preserve all original tags. If the customer requires structured tag-based segmentation (e.g., skill tags, certification tags), we map these to a multi-select custom field on Candidate to enable filtered search and reporting in Bullhorn. Tag consolidation (identical tags under different casing) happens during transformation.

Resume files, cover letters, and uploaded documents extract as binary blobs from ApplicantStack candidate records. We preserve original file names and attach them to the corresponding Bullhorn Candidate record via Bullhorn's document attachment API. File type (PDF, DOCX, RTF) is preserved. Bullhorn's attachment limit per record and file size limits are checked during transformation; files exceeding Bullhorn's limit are flagged for the customer's admin to handle manually.

If the customer uses ApplicantStack Onboard separately, I-9 data, tax form records, and onboarding document packets extract as structured records with separate document blobs. These migrate to Bullhorn Candidate records with onboarding documents attached. Bullhorn's Talent Platform (formerly Able) handles onboarding workflows post-migration; we document the onboarding data mapping for the customer's Bullhorn admin to configure Talent Platform packages after migration. I-9 and tax form data migrate as document attachments rather than structured form fields because Bullhorn does not have native I-9 storage in the core ATS.

ApplicantStack email template content migrates as Bullhorn Email Template records. Bullhorn uses a different variable/tag syntax than ApplicantStack (e.g., {Candidate.FirstName} versus ApplicantStack's equivalent). We map the template content and flag variable placeholders that require updating to Bullhorn's syntax post-migration. Automated send triggers and sequence logic do not migrate; these are documented in the automation inventory delivered to the customer's admin.

ApplicantStack job board distribution settings (Indeed sponsored jobs, JobTarget, custom branded boards) are platform-specific configuration that do not carry forward to Bullhorn. The job posting content migrates as JobOrder records; the distribution settings are documented as a configuration checklist for the customer's Bullhorn admin to rebuild in Bullhorn's job distribution settings. This is not a data gap—it is a standard rebuild item.

ApplicantStack's custom Reports exports are the source data for migration; they do not have a Bullhorn equivalent to migrate. We document every ApplicantStack Report the customer has configured (report name, fields, filters, schedule) as a configuration handoff so the Bullhorn admin can rebuild equivalent reports using Bullhorn's reporting module. Bullhorn Analytics (Canvas) is a separate add-on at $40-$60 per user per month.

ApplicantStack custom properties added to Candidates or Jobs beyond the standard schema migrate as Bullhorn custom fields. We create the destination custom fields during the schema provisioning phase using Bullhorn's Admin Field Mappings tool. Bullhorn has edition-gated limits on custom fields per entity (Candidate, JobOrder, ClientCorporation, etc.); we confirm the Bullhorn edition during scoping to ensure the custom field count fits within the contracted limit.