Migrate from Varbi Recruit to Bullhorn ATS & CRM

Varbi Candidate records map to Bullhorn Candidate. The mapping includes firstName, lastName, email, phone, address, and social security numbers (handled under explicit customer consent during scoping per GDPR Article 9 requirements). We export via Varbi CSV or API, transform to Bullhorn Candidate field types, and insert via Bullhorn REST API. Any national identity numbers (such as Swedish personnummer) are excluded from the standard payload unless the customer provides written consent during scoping and a secure transfer path is configured.

Varbi Advert records (title, description, department, location, employment type, application deadline) map to Bullhorn JobOrder. The JobOrder.title, description, and address fields are populated directly. Employment type maps to the Bullhorn employmentType field. Application deadline maps to dateCreated or a custom field depending on Bullhorn edition configuration. We preserve the advert metadata alongside candidate applications to maintain full application context in Bullhorn.

Each Varbi Application links a Candidate to a Job Advert with a Hiring Process and Stage. This maps to Bullhorn JobSubmission with the Candidate and JobOrder references resolved at migration time. The application status and timestamp migrate to JobSubmission.status and the applicable date field. Stale or duplicate applications are flagged for the customer's review before insertion.

Varbi Hiring Processes define stage sequences with tenant-defined stage names. We audit every distinct Hiring Process and stage name during scoping, then map each to a Bullhorn Record Type (one per Hiring Process) with a corresponding Sales Process that whitelists the equivalent Bullhorn StageName values. Stages with no clear Bullhorn equivalent are flagged as collapsed or expanded, requiring a hiring manager sign-off before the mapping is committed. Bullhorn StageName values are standardised (New Order, Interview, Extended, etc.), so re-mapping is required for every source stage.

Varbi Competency profiles are used in structured interview scoring and candidate comparison. Bullhorn does not have a native Competency object. We map competency frameworks to Bullhorn Custom Objects (Front Office Growth or Enterprise tier supports up to 10 custom objects with 55 fields each) or to custom fields on the Candidate record. The mapping includes competency name, description, and scoring rubric where the destination edition supports it. Where Bullhorn's edition limits custom objects to 2 (ATS tier), we flag the constraint and recommend a priority ranking for the fields to migrate.

Varbi Interview Scorecards capture structured ratings and notes against Competencies per interview stage. Bullhorn does not have a native structured scorecard object. Scorecard data migrates to Bullhorn Note records linked to the Candidate, or to a Custom Object (where available on the destination edition) with fields for competency, rating, and notes. We preserve the interview stage reference and timestamp. The customer's admin rebuilds structured scorecard forms in Bullhorn using the Custom Object configuration guide.

Varbi allows organisations to define arbitrary custom fields across Candidates, Applications, and Adverts with no enforced schema standardisation. We audit all custom fields during scoping, flatten multi-select fields into delimited columns, and map each to either Bullhorn standard custom fields (Candidate, JobOrder, JobSubmission) or Bullhorn Custom Objects. Fields that cannot be flattened due to nested or multi-level structure are flagged for manual recreation in Bullhorn. Bullhorn ATS tier limits custom objects to 2; ATS Growth has none; Front Office Growth and Enterprise allow up to 10.

CVs, cover letters, portfolios, and other documents attached to Varbi candidate profiles migrate as Bullhorn ContentDocument and ContentVersion records. Binary attachments export alongside record metadata from Varbi, are stored in a mapped folder structure, and are linked to the corresponding Bullhorn Candidate record via ContentDocumentLink. Resume parsing settings in Bullhorn are configured post-migration to re-parse imported CVs.

Varbi offer letters and contract attachments linked to candidates at the offer stage migrate as Bullhorn Candidate attachments. We export the offer record metadata (offer date, compensation, terms) to custom fields on the Candidate record or to a Bullhorn Custom Object if available on the destination edition. Offer workflow automation does not migrate; Bullhorn's offer workflow configuration is handled separately by the customer's admin post-migration.

Varbi user accounts (recruiters, hiring managers, approvers) map to Bullhorn User records. User identity includes email, first name, last name, and role. We export the user directory and map owner and user assignment fields by email match. Owners without a matching Bullhorn User are held in a reconciliation queue for the customer's admin to provision before record import resumes. This step is required before any record with an OwnerId can be inserted.

Varbi tags used for candidate segmentation, sourcing channel, or internal categorisation export as flat label arrays. We map these to Bullhorn multi-select picklist fields on the Candidate record or to a text field depending on the volume and format. Bullhorn editions with field character limits require tag prioritisation if the customer uses more tags than fit within the destination field constraint.

Varbi's digital onboarding module is a separate product layer triggered after offer acceptance. Onboarding task lists, workflow states, and onboarding documents are not included in the standard candidate or advert export and do not map to any Bullhorn object. We flag this during scoping and recommend treating onboarding as a separate workstream with its own data export from Varbi and configuration in Bullhorn's onboarding module (Bullhorn Onboarding, formerly Able) or a third-party tool. Customers should not expect onboarding records to flow automatically as part of the ATS migration.