Migrate from Team Engine to Bullhorn ATS & CRM

Team Engine Job records (title, description, location, requirements, posting status, post-date, closing date) map directly to Bullhorn JobOrder. The JobOrder status field maps from Team Engine's posting status. We preserve post-date and closing date as standard date fields on the Bullhorn JobOrder. JobOrder addresses and location data migrate to the JobOrder address fields or to a custom address field depending on the Team Engine export format.

Team Engine Applicant records (name, contact info, application date, status: applied/screening/hired/rejected, source, rejection reason) map directly to Bullhorn Candidate. The application status maps to the corresponding Bullhorn Candidate status or a custom status field. Application date migrates as dateApplied. Source attribution maps to Candidate source field. We flag records with a rejected status so that the customer can decide whether to import rejected candidates as inactive Bullhorn Candidates or exclude them from the initial migration.

Team Engine Employee records (name, contact details, hire date, group membership) map to Bullhorn Candidate by default. For firms where some employees are also client contacts, we map those to ClientContact with a dual-link. Hire date migrates as dateAdded or to a custom hire date field. Group membership maps to Bullhorn tags (see Employee Groups). We validate that each employee record has a unique email or phone before import to avoid Bullhorn duplicate violations.

Team Engine Employee Groups (customizable groups by role, shift, location, or trade) map to Bullhorn Tags as string values on the corresponding Candidate or Contact record. Group names are preserved as-is. We flag any group name collisions with existing Bullhorn tags during scoping. If the customer requires group-based filtering in Bullhorn reports, we recommend a custom Candidate field rather than relying solely on tags for organizational hierarchy.

Team Engine message threads are organized by contact phone number, not by employee record. We resolve each thread to the corresponding Bullhorn Candidate or ClientContact by matching the phone number. Thread content migrates as Bullhorn Task records with a custom body field or as Note records linked via ContentDocumentLink to the parent entity. The migration notes the original Team Engine thread start date and participant phone number for reconciliation. Unlinked contacts (applicants not hired with no Bullhorn Candidate record) are held in a reconciliation queue for the customer to decide whether to create stub Candidate records or exclude message history.

Team Engine Referral records (referring employee, referred applicant, referral status) require a Bullhorn custom object because Bullhorn does not have a native referral object. We open a Bullhorn Support ticket during migration planning to provision the custom object with fields for referral_source (lookup to Candidate), referring_employee (lookup to Candidate/User), and status. The custom object must be configured by Bullhorn Support before any referral data can be imported via the REST API.

Team Engine automated onboarding and exit survey responses map to a Bullhorn custom object linked to the corresponding Candidate. Survey question text is not migratable as Team Engine stores responses without the full question schema in the data export; we document the survey structure separately so the customer's Bullhorn admin can configure the equivalent fields in the custom object. A Bullhorn Support ticket is required to provision this custom object as well.

Team Engine automated triggered messages (new hire alerts, milestone reminders, survey triggers) are platform configuration, not data records. There is no documented export for automation rules. We cannot migrate workflow logic to Bullhorn. We perform a configuration audit of all active Team Engine triggers and deliver a written inventory listing each trigger's name, condition, action, and a recommended Bullhorn Automation equivalent for the customer's admin to rebuild manually in Bullhorn.

Team Engine custom fields are not well-documented in public API references and require manual discovery during scoping. We extract the full Team Engine field inventory from the CSV export, identify which are standard versus custom, and map custom fields to either Bullhorn custom fields (on standard entities) or Bullhorn custom objects (for structured data). Bullhorn custom fields on standard entities (Candidate, JobOrder, ClientContact) are available from any edition and are configured via Admin > Field Mappings. Bullhorn custom objects require a Bullhorn Support ticket.

Team Engine owner assignments (on Jobs, Applicants, Employees) map to Bullhorn User by email match. We resolve each Team Engine owner to a Bullhorn User record during migration. Owners without a matching Bullhorn User are held in a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes.

If Team Engine has any client or company records beyond the employee context, they map to Bullhorn ClientCorporation. Team Engine's primary use is workforce management rather than client relationship management, so this mapping applies only if the Team Engine instance contains client records. We confirm the existence and volume of company records during scoping.

If Team Engine tracks placement or hire outcomes (which may exist as an extension of the Applicant record for companies using Team Engine for temp staffing), these map to Bullhorn Placement. The mapping includes the Candidate reference, JobOrder reference, start date, and status. Bullhorn Placement is the canonical record for staffing agency billing and payroll workflows.