Migrate from Jobtrain to Bullhorn ATS & CRM

Jobtrain Vacancy records map to Bullhorn JobOrder. We map vacancy reference number to externalID for deduplication, job title, grade/level, department, cost centre, advert sources, and description. Jobtrain's custom vacancy fields map to Bullhorn custom fields on JobOrder (requires Bullhorn Support to provision if migrating custom vacancy fields on ATS Growth or ATS tier, which only support 2 custom objects total; Front Office Growth and Enterprise support up to 10 custom objects with 55 fields each). Approval route status is captured as a text property for the admin to rebuild in Bullhorn.

Jobtrain Candidate profiles map directly to Bullhorn Candidate. We map contact details (name, email, phone, address), source attribution, application history as linked records, and any custom candidate fields. Candidate is staged after Vacancy so that the JobOrder exists for application linkage. Attachment files (CVs, cover letters) export from Jobtrain and attach to Bullhorn Candidate via ContentDocumentLink.

Jobtrain Application records link a Candidate to a Vacancy at a specific stage. We sequence Application migration after both Candidates and Vacancies are staged in Bullhorn. The mapping preserves application date, current stage, and stage history as text properties. Bullhorn JobSubmission (also called CandidateJobOrderShift in some API versions) is resolved via CandidateID and JobOrderID lookups.

Jobtrain vacancy templates are reusable structures defining interview stages, questions, and approval routes. Bullhorn does not have a native vacancy template object, so we map template content to a Bullhorn JobOrder as a configuration reference document and attach it as a content note. The customer's Bullhorn admin rebuilds the template structure using Bullhorn's job order fields and any Bullhorn Automation workflow if licensed.

Jobtrain allows clients to define custom job grade and level hierarchies (e.g., Band 5, Grade 7, PO1). We map these as text fields on JobOrder if the destination Bullhorn tier supports custom fields, or as values in a dedicated Grade custom object if the customer requires structured grade lookups. Bullhorn ATS Growth and ATS tier allow custom fields on standard objects; Enterprise tier allows custom objects with 55 fields.

Jobtrain approval routes define unlimited configurable approval chains per vacancy or division. Bullhorn's approval workflow model is different and does not accept a direct migration of route topology. We document the approval chain structure during scoping, capturing the route name, approver sequence, routing conditions, and escalation rules as a written handoff document for the customer's Bullhorn admin to configure using Bullhorn's workflow engine or Bullhorn Support. Approval routes are flagged as out of scope for automated migration.

Jobtrain cost centres are defined in settings and used to categorise vacancies. We map cost centre codes and names to a text field on JobOrder (costcentre__c) or to Bullhorn's Division object if the customer has configured it. Bullhorn does not have a native cost centre field on JobOrder, so the mapping attaches cost centre as a tagged property that the customer's admin can configure as a filter or reporting dimension.

Jobtrain Departments are organisational units used to categorise vacancies and approver routing. Bullhorn has a native Department object. We map department names and IDs and attach them to JobOrder records. Department hierarchies in Jobtrain (if multi-level) are flattened to a single department name on Bullhorn with a parent-department reference stored as a custom field if required.

Jobtrain stores email and letter templates used during recruitment stages. We export template content as structured text and attach it to the relevant Bullhorn JobOrder or Candidate record as a content note. Bullhorn has an Email Template object that stores templates for candidate communication; we map the template name, body content, and associated vacancy type as a reconstruction guide. Full template import into Bullhorn's Email Template object requires admin re-entry or Bullhorn Support configuration.

Jobtrain advert sources include origin channels (Indeed, LinkedIn, agency website) and associated costs for reporting. We map source names and attributions to a text field on Candidate (source__c) or JobOrder (advertSource__c). Bullhorn does not have a native advert source field on Candidate; the value attaches as a tagged property for the customer's admin to configure as a reporting dimension.

Jobtrain onboarding templates, employment contracts, and offer letters are document-centric objects stored with limited structured metadata. Bullhorn does not have a dedicated onboarding document module on standard ATS tiers. We export the document files and metadata we can retrieve from Jobtrain as a file archive and flag which records require manual re-creation or re-upload at Bullhorn. Onboarding templates are out of scope for automated migration.

Attachments on Jobtrain vacancies, candidates, and applications (CVs, cover letters, interview notes) are downloadable via the Jobtrain interface. We export them as files and associate them with the correct Bullhorn record via ContentDocumentLink. Bullhorn's ContentDocument model requires the ContentVersion and ContentDocument records to be created first, then linked to the parent Candidate or JobOrder record. Large attachment volumes (over 10,000 files) require chunked processing to stay within Bullhorn API rate limits.

Jobtrain allows super-users to create custom fields across vacancy, candidate, and application objects. Every customer's Jobtrain instance has a unique custom field set. We discover the full custom field schema during scoping and map each to a Bullhorn custom field on the corresponding standard object (JobOrder, Candidate, JobSubmission). Bullhorn ATS Growth and ATS tiers allow 2 custom objects with 55 fields each; Front Office Growth and Enterprise allow 10 custom objects with 55 fields each. Custom objects require a Bullhorn Support ticket to provision, which we raise on the customer's behalf during schema design.