Migrate from Built to Bullhorn ATS & CRM

Built Employee records map to Bullhorn Candidate records. Each Employee's first name, last name, and email map directly to Bullhorn Candidate fields. The Built employee ID is preserved in a Bullhorn custom text field for cross-reference. Start date from Built maps to a custom date field on Candidate. Employment type (full-time, part-time, contractor, temporary) maps to a Bullhorn custom picklist field. Job title from Built maps to a custom text field on Candidate because Bullhorn does not have a native job title field on the Candidate object.

If the migration includes former employees or contacts stored in Built who should appear as client contacts in Bullhorn (for organizations with internal recruiting functions), we map to ClientContact instead. The mapping logic follows the same name, email, and custom field structure but targets the Bullhorn ClientCorporation-linked contact record type. The customer specifies during scoping which Built employee records should map to Candidate versus ClientContact.

Built Department records represent organizational units. Bullhorn does not have a native Department concept on Candidate. We create a custom object or custom picklist field in Bullhorn to represent the department name. Department heads are resolved by matching the manager assignment on the Built Employee to a Bullhorn Candidate and storing that as a custom reference field. Bullhorn Support must set up any custom object before migration begins.

Built Location records represent office sites or remote-work designations. Bullhorn Candidate has a Address fields but not a structured Location field. We map the primary location name to a custom text field on Candidate. For organizations with multiple office-based versus remote employees, we also create a custom picklist field for work arrangement type (onsite, remote, hybrid) populated from the Built Location type. Field naming is agreed with the customer during scoping.

Built stores the reporting relationship as an Employee-to-Employee link rather than a standalone field. We perform a two-pass import: first load all Candidate base records from Built Employees, then resolve manager references by matching the manager's Built employee ID against the destination Bullhorn Candidate IDs. The resolved manager is stored in a custom text field holding the Bullhorn Candidate ID of the manager. Circular manager assignments are detected and flagged before the second pass runs. Bullhorn Support can optionally configure a custom lookup relationship if the org has customObject schema available.

Built stores job title as a field on the Employee record. Bullhorn Candidate does not have a native job title field. We map job title to a custom text field on Candidate with a 100-character limit. If the customer's job titles exceed this, we truncate with a suffix flag and store the full title in a separate custom long-text field.

Built tracks full-time, part-time, contractor, and temporary employment types. Bullhorn has a native isW2 field for W-2 contractor status but no generalized employment type field. We create a custom picklist field with values matching the Built enumeration: Full-Time, Part-Time, Contractor, Temporary, and Other. The customer reviews the picklist during scoping to confirm values align with their specific Built data.

Built organizations can define custom properties on Employee records. We extract the full custom field schema via the Built API at migration start, including data type and picklist values. Each custom field is mapped to a Bullhorn custom field of equivalent type: text fields to Bullhorn text, picklists to Bullhorn picklist, dates to Bullhorn date. Custom objects in Bullhorn (customObject3 through customObject10) require Bullhorn Support to configure before migration; we coordinate this during the scoping phase and confirm schema readiness before data import begins.

Built stores documents and uploaded files against Employee profiles, but these are not included in the standard API export. We request a separate file-level export from Built support. Extracted files are organized into a folder structure keyed by Built employee ID, then re-linked manually in Bullhorn as Candidate document attachments. This requires Bullhorn's document attachment workflow or a file migration tool. We do not automate the file re-link step inside standard migration scope; it is handled as a parallel file batch with documented linking instructions.

The visual org chart in Built is a rendering of underlying employee hierarchy data, not a separate data object. Bullhorn has no native org chart capability. We extract the underlying Employee and relationship data (the structure that powers the org chart) and migrate that as Candidate records with manager references. The visual render does not migrate. If the customer requires an org chart in Bullhorn, they would need a third-party visualization tool or a custom build post-migration.

Built's ADP integration configuration is specific to Built's import mechanism from ADP payroll data. Bullhorn does not use ADP sync in the same way; Bullhorn connects to ADP through different integration paths (ADP Marketplace or third-party connectors) if the organization uses ADP for payroll. The ADP sync configuration in Built has no Bullhorn equivalent. We document the current ADP field mappings during scoping so the customer's Bullhorn admin can configure the ADP connection separately post-migration if applicable.

Built Department records may include a department head assignment. We map the department head to a custom text field on the Bullhorn custom object representing the department (or as a reference field on the department custom object). The value stored is the Bullhorn Candidate ID of the resolved employee who serves as department head. This field is populated during the second-pass manager resolution phase after all Candidate records exist in Bullhorn.