Migrate from Kallidus Recruit to Bullhorn ATS & CRM

Kallidus Recruit Candidates map directly to Bullhorn Candidates. The primary contact fields (name, email, phone, address, candidate profile) transfer to Bullhorn Candidate. We use the candidate email address as the dedupe key during import to avoid duplicate records. Candidate status history from Kallidus (active, screening, interview, offer, placed) maps to Bullhorn Candidate status fields. Any notes attached to the Candidate record migrate as Bullhorn Note records linked via ContentDocumentLink.

Kallidus Recruit Vacancies map to Bullhorn JobOrder records. Role title, department, location, job description, opening date, and closing date transfer directly. The Kallidus pipeline stage model maps to Bullhorn JobOrder status (Open, Interview, Offer, Extended, Filled, Closed). We inventory every custom vacancy field during scoping because customer-defined fields on Vacancy are not always consistently exposed in Kallidus exports; these require manual field creation in Bullhorn using Bullhorn's custom field editor or the Custom Objects API before the vacancy import.

Kallidus Recruit Applications link a Candidate to a Vacancy and carry status, submission date, screening notes, and interview scores. We map Applications to Bullhorn JobSubmission records, resolving the Candidate reference and JobOrder reference at migration time using the Kallidus candidate email and vacancy identifier as foreign keys. Application status transitions (applied, short-listed, rejected, withdrawn) map to Bullhorn JobSubmission status values.

Kallidus Recruit interview scheduling records (date, interviewer assignment, outcome, candidate self-scheduling confirmation) transfer as Note records or custom fields on the Bullhorn JobSubmission. Bullhorn does not have a native interview scheduling sub-object equivalent to Kallidus Recruit's interview management module, so interview outcome data is preserved as structured notes on the JobSubmission for admin reference. Candidate self-scheduling preferences do not have a Bullhorn equivalent and are noted in the handoff document for manual reconfiguration.

Kallidus Recruit User accounts (internal staff and hiring managers) split into two Bullhorn objects. Internal recruiter and admin users map to Bullhorn User records via email match. Hiring managers attached to Vacancies map to Bullhorn Contact records under the relevant Client Corporation (JobOrder). Role-based permissions from Kallidus do not transfer to Bullhorn profiles; we document the role structure in the inventory and the customer's Bullhorn admin configures profiles and permissions post-migration.

External agency recruiters who submit candidates via the Kallidus agency portal have separate contact records (agency name, contact name, email, phone). These map to Bullhorn Contact records under a Client Corporation record representing the agency. We export submission history associated with each agency contact as Note records on the Contact for reference. The agency portal submission interface does not migrate; the customer's Bullhorn admin configures external recruiter access via Bullhorn's standard client portal or VMS connector if needed.

Organisations that have added custom fields to Vacancy records in Kallidus Recruit to capture sector-specific data (for example, security clearance level, travel requirements, contract type) require manual schema creation in Bullhorn. We inventory all custom vacancy fields during scoping by exporting the Kallidus backoffice field configuration, then create matching custom fields on the Bullhorn JobOrder object using the Custom Objects API (up to 55 fields per entity). The customer reviews field names and types before we run the vacancy import. This is a manual configuration step that adds time to the scoping phase.

Kallidus Recruit email templates used for candidate communications (with merge fields for Candidate and Vacancy data) are exported as template bodies and field mapping documentation. Bullhorn email templates use a different merge field syntax and template structure. We do not migrate templates as code. We deliver a written inventory of every Kallidus email template with its body content, merge field references, and the candidate communication it triggers, so the customer's Bullhorn admin can recreate them in Bullhorn's template editor. The standard non-customisable reminder email is noted as a gap that Bullhorn's customisable templates will resolve.

Kallidus Recruit's Vacancy Poster distributes job postings to multiple boards from one place. We document the active job-board distribution list for each Vacancy (which boards, which date, current status). Bullhorn's job publishing module supports direct posting to major job boards and LinkedIn. We inventory the active board distribution and deliver it as a configuration guide; re-posting to job boards in Bullhorn is a manual step that the customer's admin performs or that can be configured as part of Bullhorn's standard job-board integration setup.

Kallidus Recruit tracks candidate status changes over time (applied, screening, interview, offer, placed, rejected). Bullhorn Candidate records do not preserve a native status history timeline beyond the current status field. We export the full status change log from Kallidus as a series of dated Note records on the Bullhorn Candidate, each stamped with the original status and timestamp, so that the hiring manager or recruiter can review the candidate's journey without referring back to the source system.

Kallidus Recruit includes built-in GDPR-compliant candidate anonymisation and redaction tooling. We document any candidates that have been anonymised or had data redacted under GDPR requests, with the redaction date and scope. Bullhorn does not have a native GDPR redaction workflow equivalent; we flag these records in the migration inventory so the customer's Bullhorn admin can apply appropriate data handling notes or engage Bullhorn's compliance documentation process if required.

Kallidus Recruit customers who use Xref for reference checks or Adobe Sign for document flows have linked records and attachments that do not export as structured data. We inventory the Kallidus integration configuration (which vacancy stages trigger Xref, which document types use Adobe Sign) and deliver it as a reference document for the customer's Bullhorn admin to re-establish via Bullhorn's native integrations (Bullhorn has an Adobe Sign connector in the marketplace) or to document as a gap in the Bullhorn setup.