Migrate from Dover to Bullhorn ATS & CRM

Dover Candidate records map directly to Bullhorn Candidate with name, email, phone, source, current stage, and application date transferred as standard fields. The candidate record is the primary migration unit. Stage history from Dover's stage history export table migrates as Bullhorn Opportunity records linked to the Candidate, preserving the progression timeline. Any Dover Candidate without an email address is flagged as a partial record and held for manual review before Bullhorn ingest.

Dover Candidates that represent placed or active talent who are also clients or external recruiters split into Bullhorn Contact records. We use the candidate's email domain and a type flag in the CSV to determine whether to create a Bullhorn Contact alongside the Candidate. Both records are linked so that a Candidate's placement history and a Contact's client activity coexist without duplication.

Dover Job postings (title, department, location, description, status) map to Bullhorn JobOrder. The Job-to-Candidate linkage from Dover migrates as Bullhorn Submission records that connect each Candidate to the corresponding JobOrder. We preserve the job's published status and any linked scorecard template name on the JobOrder for Bullhorn recruiters to reassign evaluation criteria post-migration.

Dover AI-generated scorecards and manually created evaluation templates export as custom fields in the candidate CSV. These map to Bullhorn user-defined fields (UDFs) on the Candidate object. Dover's numeric scoring maps to Bullhorn number UDFs; free-text evaluation notes map to text UDFs. We flag any Dover scorecard fields that exceed Bullhorn's UDF field name or type constraints and resolve them during transformation. The customer rebuilds scorecard templates in Bullhorn's native Evaluation tool post-migration.

Dover's per-job pipeline stages (Applied, Screening, Interview, Offer, Hired) extract as a per-job stage taxonomy. We map each unique Dover stage set to a Bullhorn Opportunity Record Type with a corresponding Status set. If Dover had no fixed stage names (custom per job), we standardize to a Bullhorn five-stage pipeline and preserve the original Dover stage name in a text field on the Opportunity for audit.

Dover User accounts (name, email, role, active/inactive) map to Bullhorn CorporateUser. We resolve owners by email match against the Bullhorn destination org's user table. Any Dover User without a matching Bullhorn CorporateUser is held in a reconciliation queue for the customer's Bullhorn admin to provision before candidate and job import begins, since OwnerId references are required on JobOrder and Candidate records.

If the customer used Dover's structured scorecard templates with numeric ratings, we create Bullhorn Evaluation records linked to the Candidate and JobOrder. Evaluation section scores map to Bullhorn number fields on the Evaluation; overall recommendation maps to a picklist UDF. Dover AI-generated scores that lack a structured template format are stored as text UDFs on the Candidate record as a fallback.

Dover Candidates sourced from specific job boards or referral channels with no active job assignment map to Bullhorn Lead records rather than Candidate records. The source field (LinkedIn, Indeed, Referral, etc.) from Dover populates the LeadSource on the Bullhorn Lead. Active applications remain as Candidate-to-JobOrder links. This split is computed at migration time using the candidate's job association column in the CSV export.

Dover job board API credentials (LinkedIn, Indeed, X/Twitter, and 100+ others) are stored as settings in Dover and are not records in the candidate data model. We document every active job board credential from the Dover settings export and provide a configuration checklist for the customer's Bullhorn admin to re-enter or reconnect these integrations in Bullhorn post-migration. Job board postings themselves do not migrate; we provide a list of active postings to recreate.

The Dover Recruiting Marketplace is a separate external service connecting companies with external recruiters. It is not part of Dover's core ATS data model and has no equivalent in Bullhorn's standard data model. We exclude it from migration scope and flag it in the data inventory for the customer to decommission or migrate through the separate marketplace platform's own export tools.

Dover's Gmail and Calendar OAuth integrations store scheduling and email history in Google, not in Dover's database. These are not included in the CSV export. We document candidate records with linked Google activity for the customer to re-connect the Bullhorn Gmail integration post-migration and preserve scheduling continuity. Interview invitations and calendar events do not migrate.

Dover Premium tier AI applicant scores and AI-generated interview notes export as custom fields in the CSV. We map these to Bullhorn free-text or number custom fields on the Candidate object. If the customer relies heavily on Dover's AI scoring as the primary evaluation signal, we flag that Bullhorn's Kyloe AI for Bullhorn is a separate product requiring additional licensing and configuration, and the AI scoring model does not transfer between platforms.