Migrate from Voyse to Bullhorn ATS & CRM

Voyse candidate records map directly to Bullhorn Candidate entities. We preserve the Voyse candidate identifier as a custom field voyse_id__c for audit. Core fields (firstName, lastName, email, phone, address) map to Bullhorn Candidate fields with edit type validation applied. Voyse custom properties (skills, availability status, stage flags) migrate to Bullhorn Candidate custom fields or Custom Objects depending on the property cardinality (multi-select migrates to a custom multi-select picklist; structured records migrate to a named Custom Object on the Candidate entity). We validate field edit types against the Bullhorn API field schema before write-back.

Voyse contact records (client-facing or employee contact profiles) map to Bullhorn Contact entities. The Voyse email field becomes the dedupe key during import. We resolve the Company lookup by matching Voyse company name or domain against Bullhorn Corporation name or website. Any Voyse contact without a matching Corporation is held for reconciliation. Contact type distinctions (internal employee, external client contact) map to a Bullhorn custom field or category if the customer has a Contact type taxonomy defined.

Voyse company records (organisations associated with candidates or clients) map to Bullhorn Corporation. The Corporation is the parent entity for Contacts, Job Orders, and Opportunities, so it is migrated first in the dependency chain. We set Corporation.name from Voyse.companyName and Corporation.website from Voyse.companyDomain for dedupe and lookup resolution. Bullhorn Corporation accepts custom fields for industry classification, staff count, and billing contact details.

Voyse job postings or vacancy records map to Bullhorn Job Order (the Bullhorn internal name for job record). Job title, description, location, employment type, and salary fields map directly. The Voyse job status (open, filled, closed) maps to Job Order status in Bullhorn. If Voyse tracks job-to-candidate assignments, we resolve the Candidate lookup during migration. Bullhorn Job Order custom fields capture any Voyse-specific job attributes not covered by standard fields.

Voyse records tracking a candidate placed into a role map to Bullhorn Placement. Placement requires both a resolved Candidate lookup and a resolved Job Order lookup, so it migrates after both parent entities are confirmed in Bullhorn. We map Voyse placement start date, end date, and billing rate to Bullhorn Placement date fields and custom billing fields. Commission tracking in Voyse maps to Bullhorn PlacementCommission records if the customer maintains commission data in Voyse.

Voyse employee profiles (records that combine personal data with employment data such as start date, department, manager, and onboarding stage) cannot map to a single Bullhorn entity because Bullhorn separates personal candidate data (Candidate) from placement and employment data (Placement and related Custom Objects). We split the profile into a Bullhorn Candidate record for personal data and a Custom Object (EmployeeData or OnboardingData) for employment attributes including manager, startDate, department, and onboarding stage. The split rule is defined during scoping based on the customer's Voyse data model.

Voyse onboarding workflow stages (pre-hire, documentation, training, active) have no direct Bullhorn standard field equivalent. We migrate these as a Bullhorn Custom Object attached to the Candidate or Placement record, with stage name, enteredDate, and completedDate fields. Bullhorn ATS edition limits to 2 searchable Custom Objects per entity; if the customer exceeds this, we recommend attaching onboarding data as a bullhornnative Custom Object for searchable stages and non-searchable stage notes as custom fields.

Voyse-uploaded documents (CVs, contracts, onboarding paperwork) migrate as Bullhorn ContentDocument records with ContentVersion for versioned file content. We preserve the original filename and file extension, and link each document to the parent entity (Candidate, Contact, Job Order, or Placement) via ContentDocumentLink. Bullhorn's file size limits (default 25 MB per file; configurable higher for enterprise) apply to the migrated documents.

Voyse custom properties that are single-value per record map to Bullhorn custom fields on the appropriate entity. Multi-value or structured custom properties (key-value pairs, JSON-like data) map to Bullhorn Custom Objects with a 1:N or 1:1 relationship to the parent entity. We validate each Voyse custom property against Bullhorn's field edit type options (text, number, date, dropdown, multi-select, picker types) during the pre-migration schema audit and flag any that exceed Bullhorn's 55-field per Custom Object limit.

Voyse skill tags stored against candidates migrate to Bullhorn Skill entities. Bullhorn Skills are managed through a dedicated Skills module and linked to Candidate records via CandidateSkill records. We preserve skill name, proficiency level (if available in Voyse), and the date the skill was added or verified. Skills without proficiency in Voyse are imported as Skill with no proficiency rating.

Voyse users referenced as owners, assignees, or recruiters on any record map to Bullhorn User entities. We resolve users by email address match. Any Voyse user without a matching Bullhorn User is held in a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. User permissions, roles, and team assignments require manual configuration in Bullhorn after migration.

Voyse engagement records (notes, comments, activity log entries) attached to candidate or employee profiles migrate to Bullhorn Note entities linked to the parent Candidate or Contact via ContentDocumentLink. Voyse engagement timestamps are preserved as Note.createdDate. Bullhorn does not have a native activity timeline equivalent to some ATS platforms; we use Notes to preserve the engagement record with the original Voyse text content and author attribution.

Voyse tags (flat labels attached to candidate or job records) migrate to Bullhorn Category entities or to a custom multi-select picklist field depending on whether the customer uses Bullhorn's native Category taxonomy. Tags used for Boolean flags (active, verified, priority) migrate to Bullhorn custom checkbox fields. The customer chooses the tag strategy during scoping based on whether Bullhorn Categories are already in use in the destination org.