Migrate from Vultus Recruit to Bullhorn ATS & CRM

Vultus Openings map to Bullhorn JobOrder records. The opening title, description, status, location, and creation date migrate directly. Department, salary range, and employment type from Vultus map to Bullhorn custom fields on JobOrder, which must be created before migration. Bullhorn JobOrder uses standard field names jobTitle, description, status, and address; the source department and salary fields require custom field creation in Bullhorn first. Pipeline stage names within Vultus Openings are preserved as a custom field on JobOrder rather than mapped to Bullhorn's native Opportunity pipeline stages, since Bullhorn JobOrder uses a separate stage model from staffing placement pipelines.

Vultus Candidate records migrate to Bullhorn Candidate. We extract name, email, phone, resume text (where exposed in the UI), source channel, current status, and owner assignment. Bullhorn Candidate supports custom fields and a skills multi-select field that maps from Vultus candidate skills data. Bullhorn allows multiple resume file attachments per Candidate; resume text from Vultus migrates as a Bullhorn Note attached to the Candidate record if Bullhorn is configured for Notes-as-resume. Any duplicate Candidates detected across the export are flagged in a reconciliation report before insert.

Vultus does not expose resume files as downloadable binary endpoints. We cannot write an API connector to retrieve them. Resume text extracted by Vultus during parsing migrates as Bullhorn Note body or custom Candidate resume text fields. Customers should expect to request resume re-uploads from candidates post-migration or to run a bulk resume parsing job using a service like Sovren or Textkernel to rebuild binary attachments in Bullhorn. We document the resume parsing gap in the migration handoff report.

Vultus Accounts map directly to Bullhorn ClientCorporation. Company name, address, industry, revenue range, and phone migrate to Bullhorn standard fields corpName, mainAddress, businessSector, and phone. Custom Account properties migrate to Bullhorn ClientCorporation custom fields. Bullhorn requires ClientCorporation to exist before any ClientContact insert because ClientContact has a required ClientCorporation lookup field. We run the Accounts migration phase first, resolve the Vultus Account IDs to Bullhorn CorporationID after insert, then use those IDs to satisfy the ClientCorporationID reference when importing Contacts.

Vultus Contacts map to Bullhorn ClientContact. Name, email, phone, title, and linked Account reference migrate, with the Account-to-ClientCorporation lookup resolved by matched company name or domain. Bullhorn ClientContact has staffing-specific fields including primaryRecruiter (User lookup) and clientCorporationID (required). Custom Contact properties from Vultus migrate to Bullhorn ClientContact custom fields. The client tier classification (if tracked in Vultus as a custom field) migrates as a custom picklist on ClientContact.

Vultus Users and Owners assigned to Candidates and Openings map to Bullhorn User records by email match. We extract user names and emails but cannot migrate Bullhorn role configurations or field-level security settings from Vultus because Vultus does not expose role data in any exportable format. The Bullhorn admin provisions User accounts before production migration; inactive User records in Bullhorn are used for historical owner assignment if the original recruiter is no longer active.

Vultus Hotlists are grouped candidate collections unique to the platform with no direct Bullhorn equivalent. We export the hotlist name and the candidate IDs contained within it, then recreate groupings in Bullhorn using Bullhorn's Tag system (a multi-select Candidate field) or a custom Candidate segment field. The customer chooses the target structure during scoping. We provide a mapping table of hotlist name to candidate ID list in the migration handoff so the Bullhorn admin can apply tags or create Bullhorn Views for each original hotlist.

Vultus mass mailing history and campaign records are not exposed as a distinct exportable object. We extract candidate email addresses and any opt-out or unsubscribe flags from the Candidate export for import into Bullhorn Candidate. Bullhorn EmailRecipient (for Bullhorn Automation email sequences) is populated with the imported email addresses; campaign-level history does not migrate. Email campaign templates and cadence sequences are not migrated because they are platform-specific and require rebuild in Bullhorn Automation (Herefish) or a sales engagement tool.

Vultus custom fields on Openings, Candidates, Accounts, and Contacts are non-standard and vary per customer. We discover all custom field names and data types during scoping from the CSV export headers and any UI-visible field labels. Bullhorn custom fields must be created in the Bullhorn UI or via Bullhorn Support before we can map data into them. Bullhorn ATS Growth edition limits custom objects to 2; customers on that tier must prioritize the most critical custom fields for migration. We provide a complete custom field mapping table with Bullhorn field creation instructions in the pre-migration handoff.

Vultus pipeline stage definitions are tied to the Opening object and vary per customer configuration. Bullhorn's native Opportunity pipeline stages are distinct from JobOrder pipeline stages used in staffing. We extract current stage labels and order from Vultus and create a Bullhorn JobOrder custom picklist field to preserve the original stage names post-migration. The customer manually creates matching pipeline stages in Bullhorn's JobOrder settings; we document the current Vultus stage matrix for their admin to reference.

Workflow automation rules including stage transition logic, email triggers, and assignment automations are stored as Vultus internal platform settings and are not exposed in any exportable format. These cannot be migrated programmatically. We document the current workflow rules, trigger conditions, and actions during scoping and deliver a written inventory with recommended Bullhorn Automation (Herefish) equivalents for the customer's admin to rebuild. This work is outside standard migration scope.

Vultus integration configurations with ZipRecruiter, Indeed, and Techfetch are platform-level settings, not record data, and do not migrate. We document which job boards are currently connected in Vultus during scoping. Bullhorn's job board distribution is configured in Bullhorn's job board integration settings or via Bullhorn Marketplace connectors. The customer manually re-establishes each job board connection post-migration. This work is outside standard migration scope but we provide a configuration checklist.