Migrate from Wizehire to Bullhorn ATS & CRM

WizeHire Jobs map to Bullhorn JobOrder. Each Job carries title, description, status (open/closed/paused), location, and department. WizeHire's per-account pipeline stage names (Applied, Screening, Interview, Offer, Hired, Rejected or custom variants) map to Bullhorn JobOrder status values via a Sales Process we configure before migration. Job status (open/paused/closed) maps to the Bullhorn isDeleted flag and jobOrderStatus field. Job board distribution history from WizeHire does not transfer as integration records; we document the list of boards for reconfiguration in Bullhorn via Bullhorn Marketplace or manual setup.

WizeHire Candidate records map to Bullhorn Candidate. WizeHire creates a separate Candidate record for each application, so a single person who applied to two different jobs appears as two separate WizeHire records. During migration we identify these duplicates by comparing name, email, and phone across all WizeHire Candidate records and consolidate them into a single Bullhorn Candidate. The original WizeHire application IDs are preserved as custom fields on the Bullhorn Candidate so the audit trail is complete. Resume files attach to the Bullhorn Candidate via ContentDocumentLink.

WizeHire Application records (linking a Candidate to a Job with a status and stage-transition timestamps) map to Bullhorn JobSubmission. The JobSubmission record links the Candidate and JobOrder and stores the candidate's status within that specific job pipeline. Stage-transition timestamps (Applied date, Screening date, Interview date, Offer date, Hire date, Rejection date) migrate as custom date fields on the JobSubmission to preserve the full audit trail. If the candidate was rejected, the rejection date and reason migrate to the JobSubmission record.

WizeHire stores DISC+ personality profile results per Candidate as structured data covering Dominance, Influence, Steadiness, and Conscientiousness dimensions plus an overall profile type. Bullhorn has no native DISC+ field, so we create a custom object (customObject1s) assigned to the Candidate entity in Bullhorn with text fields for each dimension and a profile type field. We use Bullhorn's custom object metadata API to verify the available custom object assignments before creating the schema. The DISC+ raw score and narrative text migrate as separate fields within the custom object.

WizeHire scorecards store custom evaluation criteria and per-candidate scores assigned by hiring managers. Scorecard templates (criteria names, weightings) and per-application scores migrate to a Bullhorn custom object (customObject2s) on the JobSubmission or Candidate. If the scorecard data is simple (criteria + numeric score), we evaluate whether to store it as a Note with structured text format instead of a custom object to conserve custom object inventory. The customer's Bullhorn admin decides the storage strategy during scoping.

WizeHire stores custom pre-screening question text and candidate responses per Job per Application. Question text migrates as a Note attached to the JobOrder for documentation. Candidate responses migrate as a custom text area field on JobSubmission (customField4, for example) if the number of questions is consistent across all jobs. If jobs have varying question sets, we document the question-response mapping per Job in a separate JSON configuration file for the customer's Bullhorn admin to rebuild as custom fields on each relevant JobOrder.

WizeHire stores background check pass/fail flags and provider names as fields on the Candidate or Application. These migrate to Bullhorn custom fields on the Candidate record (customBoolean1 for pass/fail, customText1 for provider name). Full background check report documents migrate as ContentDocument records linked to the Candidate via ContentDocumentLink. We flag any background check data for explicit customer sign-off before migration since this may include sensitive PII subject to regional compliance requirements.

WizeHire's customizable pipeline (Applied, Screening, Interview, Offer, Hired, Rejected or account-specific variants) maps to Bullhorn's JobOrder status field within a Bullhorn Sales Process. We export the full stage name and order from WizeHire and configure a Bullhorn Sales Process that whitelists the exact stage values in the same order. Stage probabilities from WizeHire map to the corresponding Bullhorn stage probability percentages. The Sales Process is assigned to a Record Type on JobOrder that matches the customer's placement type (direct hire, temp-to-perm, contract).

WizeHire provides 100+ industry-tested job templates stored as organizational configuration data. We export templates as structured text records and handle them as documentation in the migration handoff. Bullhorn does not have a native job template object; templates are re-created using Bullhorn's JobOrder duplication feature or stored as Notes on a designated Bullhorn Admin JobOrder that the customer's team references when creating new jobs. We deliver a CSV of template names and content for the Bullhorn admin to load.

WizeHire Interview Guides are attached to Jobs and outline questions and evaluation criteria. Bullhorn has no native interview guide object. We export interview guide text per Job and attach it as a Note on the corresponding Bullhorn JobOrder with a type of 'Interview Guide'. Bullhorn's Field Mappings tool allows the admin to add a custom Interview Guide label if they want a visible custom field on the JobOrder layout instead of using Notes.

Hiring team notes stored in WizeHire on Candidate profiles (text entries with author name and timestamp) migrate to Bullhorn Note records attached to the Candidate. The Note body preserves the full text. We set the Note's createdDate to the original WizeHire timestamp to preserve the chronological order of the candidate's evaluation history. Author attribution migrates as the Note's ownedBy field by resolving the WizeHire user email against Bullhorn User records.

WizeHire users tag candidates with custom labels for filtering and segmentation. Tags stored as a list per Candidate migrate to Bullhorn custom fields on the Candidate record. If the tag vocabulary is consistent and bounded (fewer than 50 distinct tags), we create a custom multi-select picklist field and map each tag to a picklist value. If the vocabulary is unbounded or frequently changing, we use a custom text field and store tags as comma-separated values. The customer decides the strategy during scoping.

WizeHire user accounts (hiring managers, admins) with roles and names migrate as Bullhorn User records. We export WizeHire users by email and name and match by email against the Bullhorn destination org's User table. Any WizeHire user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record migration proceeds. OwnerId references on JobOrder, Candidate, and JobSubmission are resolved at migration time using the User mapping.