Migrate from Applicant Starter to Bullhorn ATS & CRM

Applicant Starter Candidates map directly to Bullhorn Candidate records. The core fields (name, email, phone, resume) migrate as typed Bullhorn Candidate fields. We download resume files as binary blobs, name them consistently using candidate ID and timestamp, and attach them to the Bullhorn Candidate record via ContentDocumentLink. Any Applicant Starter candidate ID is preserved as a reference field bullhorn_migration_source_id__c for audit and deduplication.

Applicant Starter job postings map to Bullhorn Job Order records. The original job ID is preserved as a reference field. Bullhorn Job Orders have a richer schema than Applicant Starter including EdCode, StartDate, FeePercent, and OPRecordType; during scoping we extract every active and closed job field from Applicant Starter and map them to Bullhorn equivalents or custom fields. Open/closed status from Applicant Starter maps to Bullhorn's status field (Open/Closed/Hold/Canceled).

Applicant Starter allows free-form stage names per account. We extract the full stage taxonomy during scoping (Applied, Screening, Interview, Offer, Hired in one account; Open, Qualified, Shortlisted, Placed in another). Bullhorn stages are configured as Sales Processes per Job Order Record Type with specific StageName values and probabilities. We build a custom stage map during scoping that resolves each Applicant Starter stage to a Bullhorn equivalent, flagging any that have no logical counterpart.

Applicant Starter stores activity logs (calls, emails, interview notes) as a stream attached to a candidate. Bullhorn separates these: calls map to Task with TaskSubtype=Call and CallDurationInSeconds; interview notes map to Note records linked via ContentDocumentLink; emails map to EmailMessage records linked to the Candidate. We decompose the Applicant Starter activity stream into Bullhorn's typed activity objects preserving timestamps for timeline ordering. Some older Applicant Starter activities may lack timestamps; we flag these and assign them a placeholder date for visibility.

Applicant Starter may store minimal company data alongside candidates. Bullhorn has a dedicated Client Corporation object with fields for billing address, industry, annual revenue, and owner. If Applicant Starter contains company data (name, address, contact), we map it to Bullhorn Client Corporation. If company data is sparse or absent in Applicant Starter, we create placeholder Client Corporation records from candidate company associations for completeness.

Applicant Starter tracks where each job was distributed (LinkedIn, Indeed, job boards). Bullhorn Job Orders have a built-in posting distribution history. We map Applicant Starter job distribution records to Bullhorn Job Posting entries tied to the corresponding Job Order, preserving the posting date and distribution channel.

Applicant Starter custom fields on Candidates or Jobs require explicit mapping. Bullhorn's Custom Objects (Growth/Enterprise: up to 10 Custom Objects with 55 fields each; Corporate+: Custom Fields and Workflows) provide the destination schema. We extract the Applicant Starter custom field schema during scoping, map each to a Bullhorn Custom Object or custom field, and pre-create the destination schema before any data import. Bullhorn ATS Growth does not support Custom Objects; if the destination is ATS Growth, custom fields from Applicant Starter must be absorbed into standard Candidate or Job fields or noted as unmapped.

Applicant Starter Scorecard data, if present, is stored in a proprietary format not accessible via the export API. Bullhorn does not have a native scorecard object at the standard ATS level; evaluations are handled via custom fields or Bullhorn's Canvas reporting. We notify customers during scoping and advise manual export or screenshot-based handoff. No scorecard data migrates programmatically.

Applicant Starter uses a tag taxonomy per account to classify candidates (skills, source, clearance level, etc.). Bullhorn Candidate records support a Tags field (multi-select picklist) and Custom Objects for more structured tagging. We map Applicant Starter tags to Bullhorn Candidate Tags for simple taxonomies or to a Custom Object for complex multi-dimensional tagging schemes.

Applicant Starter owners (recruiters, hiring managers) map to Bullhorn User records. We resolve owners by email match against the Bullhorn destination org's User table. Any Applicant Starter owner without a matching Bullhorn User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Resume files and binary attachments from Applicant Starter are downloaded during export, named consistently using candidate ID and original filename, and uploaded to Bullhorn as ContentDocument records attached via ContentDocumentLink to the corresponding Candidate record. We preserve the original upload timestamp as ContentVersion's Origin field.

Applicant Starter does not have a native Placement object; Bullhorn's Placement record represents a candidate placed in a job for a client. When Applicant Starter contains placed candidates, we map them to a Bullhorn Job Order (if not already created) and a Bullhorn Placement linked to the Candidate and Job Order. If Applicant Starter tracks placement status only as a stage value, we create Placement records post-migration based on the stage mapping.