Migrate from Fountain to Bullhorn ATS & CRM

Fountain Applicant records map to Bullhorn Candidate. The Fountain applicant ID becomes a custom field fountain_applicant_id__c on the Bullhorn Candidate for audit traceability. Fountain's application date, current stage, and stage history migrate as Bullhorn Candidate custom fields and Application V2 records where available. Hiring source attribution (how the candidate applied) migrates to a bullhorn_hiring_source__c custom field on Candidate. Fountain's mobile-optimized application fields (shift preference, availability windows) map to Candidate custom fields with free-text or picklist types.

Fountain Job Posts map to Bullhorn JobOrder. The Fountain job title, description, and requirements map to JobOrder title, description, andpublicDescription. Fountain's department assignment maps to JobOrder corporateUserName or a custom field department__c. Fountain job status (open, paused, closed) maps to JobOrder status with Bullhorn's open, interview, offer, filled, and closed values. Fountain job type (hourly, shift-based) becomes a custom picklist on JobOrder.

Fountain pipeline Stages map to Bullhorn Opportunity stages on the JobOrder's Opportunity track. Each Fountain stage name becomes a Bullhorn Opportunity stage value. Fountain's stage sequence order maps to the Bullhorn Opportunity Stage order. Stage probability percentages from Fountain become Opportunity probability values in Bullhorn, rounded to integer. We document the full stage-to-stage transition history from Fountain as a separate migration artifact for Bullhorn workflow rebuild.

Fountain Locations represent physical work sites (stores, warehouses, restaurants). Bullhorn has no standalone Location object; addresses attach to ClientCorporation. If Fountain Locations correspond to client worksites, we create Bullhorn ClientCorporation records for each Location, populating address fields from Fountain. If Locations represent the customer's own hiring offices, we attach address as a custom field on internal records. The mapping choice is confirmed during discovery scoping.

Fountain Departments group Jobs and hiring teams by business function. We map department names to Bullhorn Candidate and JobOrder custom fields (department__c picklist) or Business Sector on ClientCorporation depending on use. Department hierarchies from Fountain map to Bullhorn Corporate Branch if the Bullhorn edition supports it, or to a flat department custom field if not.

Fountain customAttributes with editable flags map to Bullhorn custom fields on Candidate and JobOrder. Bullhorn editions cap custom object and field counts (up to 10 Custom Objects with 55 fields each on Front Office Growth/Enterprise; 2 Custom Objects on Bullhorn ATS). We pre-create Bullhorn custom fields via the Custom Object Setup spreadsheet submitted to Bullhorn Support before migration. Field type mapping: Fountain text, number, and date map to Bullhorn String, Number, and Date types; Fountain picklist maps to Bullhorn DropDown; Fountain multi-select maps to Bullhorn CheckBox or multi-select picklist.

Fountain customAttributes with readOnly=true are system-controlled and cannot be written via API. We identify every readOnly attribute during discovery and exclude them from migration load. During Bullhorn configuration, these become Bullhorn custom fields with display labels matching the Fountain field name but populated by Bullhorn system rules or formula fields rather than imported values. We document the readOnly attribute list with its Fountain field name, type, and description so the Bullhorn admin can configure equivalent computed fields.

Fountain document attachments (hiring forms, compliance certifications, background check results) migrate to Bullhorn Candidate records via ContentDocument and ContentDocumentLink. We export document binaries in parallel batches, maintaining a filename-to-applicant-ID mapping. Each document becomes a ContentDocument record linked to the corresponding Bullhorn Candidate. Bullhorn's file size and type restrictions apply; we validate document formats during export and flag any that exceed Bullhorn's supported types. Large document volumes increase migration duration and require explicit scoping before starting.

Fountain Offer records (compensation details, start dates, offer status) map to Bullhorn Placement records. The Fountain offer status (accepted, declined, pending) becomes Placement status in Bullhorn. Start date, shift schedule, and position details migrate as Placement custom fields or standard fields depending on Bullhorn edition. We create the Placement record linked to the Candidate and JobOrder after both exist in Bullhorn.

Fountain user-added notes on Applicants (hiring manager context, interview feedback) migrate as Bullhorn Note records on the Candidate. Note content, author, and timestamp transfer. Bullhorn Note records are linked via ContentDocumentLink to the Candidate. We preserve note ordering by timestamp for interview feedback and hiring manager commentary.

Fountain's automation rules (auto-advancing candidates, email triggers, task creation per stage) are not accessible through the Fountain public API and cannot be migrated as code. We document every active Fountain workflow configuration during discovery: trigger type, conditions, stage transitions, email actions, and task assignments. This document is delivered to the customer as a Bullhorn Automation rebuild guide. The Bullhorn admin or a Bullhorn implementation partner rebuilds workflows in Bullhorn Automation post-migration. This is standard scope and is not included in migration execution.

Fountain tracks hiring source attribution per Applicant (referral, job board, direct). We create a bullhorn_hiring_source__c custom field on the Bullhorn Candidate record and populate it from Fountain's source field during migration. This preserves sourcing analytics for the recruiting team in Bullhorn without relying on standard fields that do not map directly from Fountain.