Migrate from Occupop to Bullhorn ATS & CRM

Occupop Candidate records map directly to Bullhorn Candidate. We extract name, email, phone, CV file reference, stage history, AI screening score, and any custom field key-value pairs. The Occupop custom field schema is tenant-specific with no fixed definition; we inspect the export during scoping, build a per-field map, and land values as Bullhorn custom fields on the Candidate record. Bullhorn's entity-level custom field limits apply: Bullhorn ATS allows 2 Custom Objects, ATS Growth allows none, and Front Office Growth/Enterprise allow 10. We pre-create the required Bullhorn Custom Objects (with Bullhorn Support for the initial setup) before migration and fall back to structured Note records when Custom Object capacity is exhausted.

Occupop Jobs map to Bullhorn JobOrder. We export job title, description, department, location, status (active/closed), and original Occupop job ID preserved as a custom field. The Bullhorn jobPublished flag is set based on the Occupop active/closed state. JobOrder is created before the Candidate import so that the Candidate-to-Job reference (candidateSubmissions in Bullhorn) is satisfied at import time.

Occupop tracks an ordered sequence of stages per Job (Applied, Screening, Interview, Offer, etc.). Bullhorn JobOrder does not have a native stage sequence object. We map each Occupop stage name to a Bullhorn custom field on JobOrder and preserve the full stage list as a structured Note attached to the JobOrder. Interview stage definitions and stage-specific feedback are stored as separate Note records with a category tag so the customer's Bullhorn admin can re-create the pipeline view using Bullhorn's built-in pipeline kanban.

Occupop Users (Admin, Hiring Manager, Recruiter, Viewer roles) map to Bullhorn User records by email match. We export all users with their role assignments and flag any Occupop role that has no direct Bullhorn equivalent. Bullhorn's role model (Admin, Standard, Limited) is applied as a mapping during scoping, and the customer's Bullhorn admin confirms the final role assignment before migration.

CV files are exported as raw binary files from Occupop and re-attached to the Bullhorn Candidate record via Bullhorn's ContentDocument and ContentDocumentLink objects. We preserve the original filename and the linkedCandidate relationship. Bullhorn's resume parsing is triggered post-import if the Bullhorn edition includes that feature.

Occupop interview notes and scorecard responses are stored per Candidate per stage. Bullhorn does not have a native interview-feedback object; we export the full text and scores and land them as Note records with a category tag (e.g., Interview Feedback) linked to the Candidate. If the customer requires a structured scorecard format, we use Bullhorn Custom Objects with a Bullhorn Support ticket to pre-create the schema.

Occupop's AI screening score (0-100 or similar scale depending on tenant configuration) and the Candidate's rank within the Job's candidate pool are exported as numeric fields. We create a custom numeric field on the Bullhorn Candidate object (occupop_ai_score__c) and populate it during import. The rank is stored as occupop_rank_in_job__c. These fields are available for Bullhorn reporting and sorting post-migration.

Occupop tracks which job boards a Job was distributed to (Indeed, LinkedIn, Reed, Glassdoor, niche boards) and the posting date. Bullhorn has no standard field for board-distribution history. We export this as a structured CSV per Job (job_title, board, posting_date, status) and attach it as a Note to the Bullhorn JobOrder. The customer's Bullhorn admin uses this inventory to re-create distributions through Bullhorn's job board integrations or manually post to the relevant boards post-migration.

Occupop Custom Fields are arbitrary tenant-defined key-value pairs on Candidate records. During scoping we inspect the source tenant's full custom field definitions, classify each as a scalar value (maps to a Bullhorn custom field) or structured data (maps to a Bull Object), and build a per-field type map. Bullhorn entity-level custom field limits (2-10 Custom Objects depending on edition) are verified with the customer before migration. Values that cannot fit within Bullhorn's Custom Object capacity are stored as structured text in Note records with a field-label prefix.

Bullhorn includes a separate Lead object for unqualified prospects. Occupop has no Lead concept—all applicants are Candidates. We do not create Bullhorn Lead records from the Occupop migration unless the customer specifically requests it as part of their Bullhorn onboarding process. If Lead creation is requested, unqualified Candidates (e.g., applicants who never reached an interview stage) are segmented into Lead records with the original Occupop source tagged in a custom field.

Bullhorn's CRM layer includes ClientCorporation records that represent staffing firms' client companies. Occupop does not have a client CRM object. If the customer uses Bullhorn's CRM features, we assist in scoping whether ClientCorporation records need to be created (as new records in Bullhorn, not migrated from Occupop) or whether the staffing firm's client relationships are tracked differently.

Bullhorn Placement records track hired candidates and are a core object in the staffing use case. Occupop does not have a Placement object (offer and onboarding data moved to Cezanne HR post-acquisition). Placement records are not migrated from Occupop. The customer creates Bullhorn Placement records as they make placements post-migration, using the migrated Candidate and JobOrder records as the basis.