Migrate from eRecruiter to Bullhorn ATS & CRM

eRecruiter Candidates map directly to Bullhorn Candidate records via the Bullhorn REST API. We use email as the primary dedupe key, falling back to a composite of firstName + lastName + phone when email is absent. Contact info, skills, employment history, and answers to application questions transfer to Bullhorn Candidate fields. eRecruiter CV Parsing output stored as candidate profile fields migrates as Bullhorn custom fields or custom object entries depending on the destination edition. GDPR consent flags transfer to Bullhorn's compliance fields (GDPRConsentDate, GDPRConsentSource) if configured in the destination org.

Each eRecruiter Application row generates one Bullhorn JobSubmission record linking an existing Candidate to an existing JobOrder. The eRecruiter applicationStatus (e.g., applied, screening, interview, rejected, hired) maps to the corresponding Bullhorn JobSubmission status value. If one eRecruiter Candidate has applied to multiple Jobs, each application generates a separate JobSubmission. The mapping requires that both Candidate and JobOrder are migrated and their Bullhorn IDs are resolved before JobSubmission records are inserted. We use the ExternalId from eRecruiter to track the original application reference in a custom field on the JobSubmission.

eRecruiter Jobs map to Bullhorn JobOrder records. Title, description (HTML preserved), location (city, region, country), employment type, and department transfer directly. The eRecruiter publication status (published, draft, closed) maps to JobOrder status. JobOrder.address, JobOrder.city, JobOrder.state, and JobOrder.country populate from eRecruiter location fields. If eRecruiter Jobs have associated custom fields, those map to JobOrder custom fields or custom object entries. We flag any eRecruiter Jobs with status 'closed' or 'cancelled' and discuss with the customer whether to migrate them as archived JobOrders or exclude them from the active Bullhorn instance.

eRecruiter Company entities map to Bullhorn ClientCorporation records. We use the Company Import API endpoint in Bullhorn (which supports ExternalId matching) for bulk company creation and updates. Company name becomes ClientCorporation.name, and the company website domain assists with deduplication. If eRecruiter Companies have associated custom fields, those map to ClientCorporation custom fields within the applicable edition limit. Address and industry data transfers to the corresponding ClientCorporation address and business sector fields.

eRecruiter User records (name, email, role, department) map to Bullhorn User records by email match. Role naming differs between platforms, so we capture the eRecruiter role name in a custom User field for the customer's admin to remap during Bullhorn setup. Users without a matching Bullhorn User account are held in a reconciliation queue; the customer's Bullhorn admin provisions any missing accounts before production migration. Inactive eRecruiter Users may be migrated as inactive Bullhorn Users to preserve historical assignment data.

eRecruiter Departments map to Bullhorn Teams. Bullhorn Teams are a grouping mechanism for User membership rather than a hierarchical org chart. We migrate the department name as the Team name and note that team membership assignment is a post-migration admin task because Bullhorn does not automatically associate Users to Teams based on department metadata from an external source.

Candidate and Application attachments in eRecruiter are identified by DocumentTypeName, Filename, and the parent record's ID. Bullhorn does not have a standalone document download endpoint without parent context. We transfer binary attachments only after the parent Candidate and JobOrder records are present in Bullhorn, using the Bullhorn REST API to create ContentDocument and ContentDocumentLink records linked to the migrated Candidate or JobSubmission. We flag any eRecruiter attachments where the parent Application or Candidate is absent; those documents are held in a reconciliation report for the customer to resolve before migration resumes.

eRecruiter structured evaluation ratings stored on Applications map to Bullhorn custom object entries on the corresponding JobSubmission. On Front Office Growth and Enterprise editions, up to 10 custom objects with 55 fields each are available. On Bullhorn ATS (2 custom objects) and ATS Growth (none), rating data migrates as structured Note records or Bulletins linked to the JobSubmission. The mapping type depends on the customer's active Bullhorn edition, which we confirm during scoping.

eRecruiter custom fields on Candidates map to Bullhorn Candidate custom fields (customObject1-10 or typed custom fields via Admin > Field Mappings). Bullhorn editions determine how many custom objects are available. We pre-create the destination custom field schema during the sandbox phase, deploy it via Bullhorn Support ticket, and validate that all migrated custom field values land in the correct Bullhorn fields. eRecruiter CV Parsing output is treated as custom field data and follows the same mapping path, with field names validated against the destination schema before migration.

eRecruiter custom fields on Applications map to Bullhorn JobSubmission custom fields or custom object entries. The Bullhorn custom field creation workflow requires an Admin > Field Mappings setup per entity. Bullhorn ATS is limited to 2 custom objects, Front Office Growth/Enterprise supports 10. For migrations requiring more custom objects than the edition supports, we prioritize the highest-impact fields for migration and document the remainder for post-migration admin configuration. Bullhorn Support must create custom objects before data can be written to them via API.

eRecruiter location data (city, region, country) on Jobs transfers to Bullhorn JobOrder.city, JobOrder.state, JobOrder.country, and JobOrder.address. If eRecruiter Jobs support multiple location values, each location generates a separate JobOrder with the same title and description, which is the standard Bullhorn pattern for multi-location job postings.

eRecruiter's native GDPR and RODO compliance features including consent tracking, data retention metadata, and candidate rights management transfer to Bullhorn's GDPR compliance fields on the Candidate record. GDPRConsentDate and GDPRConsentSource populate from eRecruiter consent date and consent type fields. If the customer requires CCPA compliance for U.S. operations, we map eRecruiter consent data to Bullhorn's CCPA fields (HasOptedOutOfEmail, HasOptedOutOfPhone) alongside the GDPR fields.