Migrate from unstop to Bullhorn ATS & CRM

Unstop Users (candidates and recruiters) map to Bullhorn Candidate records. Candidate profiles carry name, email, phone, education, skills, and work-history fields. We map these to Bullhorn Candidate fields (firstName, lastName, email, phone, education, skills) and preserve the original Unstop user ID in a custom field unstop_user_id__c for audit traceability. Recruiter profiles map to Bullhorn User records by email lookup during migration. Note that Unstop's self-service registration means education and work-history fields are self-reported and unverified; we flag these as requiring re-verification in Bullhorn and set a data_quality flag accordingly.

Unstop job postings (title, description, location, salary range, deadline) map directly to Bullhorn JobOrder records. The job type maps to JobOrder employmentType, and the application deadline maps to dateBegin. We use Bullhorn's JobOrder REST API to create records in dependency order (JobOrder must exist before Applications can link to it). Active job status in Unstop maps to JobOrder status = 'Open'.

Unstop internship records follow the same schema as job postings with additional fields for internship duration and stipend. We map these to Bullhorn JobOrder with a custom field internship_type__c set to true and custom fields for duration_weeks__c and stipend_amount__c. Bullhorn does not natively distinguish internships from jobs, so the internship flag lives in the custom field.

Unstop applications link a User to a Job, Internship, or Competition and track status (Applied, Shortlisted, Rejected, Hired). These map to Bullhorn JobSubmission records attached to the corresponding JobOrder and Candidate. We preserve the full status history as a JSON payload in a custom field application_status_history__c because Bullhorn JobSubmission natively tracks only current status.

Unstop quiz session records (start timestamp, end timestamp, score, passing status, device) map to a Bullhorn Custom Object we configure as QuizAttempt. Bullhorn Growth and Enterprise editions support up to 10 custom objects with 55 fields each; Bullhorn ATS supports 2. We recommend the customer provision the QuizAttempt custom object before migration scoping begins. Quiz sessions with missing end_timestamp or anomalous duration are flagged as crash-affected records requiring manual review. Original quiz configuration (time limit, question bank) migrates as a separate QuizConfig custom object or JSON attachment.

Unstop assessment configurations (quiz/test name, time limit, scoring rubric, question bank metadata) migrate as a Bullhorn Custom Object called Assessment or as a JSON payload in a custom text area field on the QuizAttempt record. Format-specific assessment fields (coding challenge metadata, design brief parameters) store as JSON in a custom field format_config__c to preserve structure without requiring a separate custom object per competition type.

Unstop competition records (name, organizer, dates, rules, format type) map to a Bullhorn Custom Object called Competition. Participant enrollment lists migrate as CompetitionEnrollment records linked to the Competition custom object, or as a JSON array in a custom field participant_list__c on the Competition record depending on the customer's Bullhorn edition and field availability. We use a format_type discriminator field to distinguish coding challenges, quizzes, design contests, and case studies.

Unstop hackathon records (name, dates, team structure, submission URLs, judging scores, leaderboard positions) map to a Bullhorn Custom Object called Hackathon. Team memberships flatten into individual participation records linked to the Hackathon custom object via a lookup relationship. We preserve submission URLs and judging scores in custom fields. Bullhorn's Growth and Enterprise editions are required for the lookup relationships; ATS edition requires storing hackathon data as JSON in a text area field.

Unstop scholarship records (name, eligibility criteria, amount, deadline, applicants) map to a Bullhorn Custom Object called Program with fields for scholarship_amount__c, eligibility_criteria__c (text area), and application_deadline__c. Applicant lists migrate as JSON in an applicants__c text area field if the customer's Bullhorn edition does not support additional custom objects.

Unstop recruiter organization profiles (company name, logo, description, contact details) map to Bullhorn ClientCorporation records. We use the organization name as the ClientCorporation name and the domain as the website field. ClientCorporation must exist before any Candidate records with a primaryClientCorporation assignment are imported.

Unstop engagement records (application submissions, competition registrations, quiz completions) that represent candidate activity events map to Bullhorn Task records attached to the Candidate. We set Task Subject to reflect the engagement type (e.g., 'Applied to: [Job Title]'), set ActivityDate to the engagement timestamp, and store the full engagement metadata as a JSON payload in a custom field engagement_data__c.

Unstop uploaded resumes, portfolio files, and certificates attach as Bullhorn ContentDocument records linked to the Candidate or JobSubmission via ContentDocumentLink. We use the Bullhorn REST API to upload files and resolve the LinkedEntityId to the migrated Candidate record. Certificate PDFs migrate with a custom field certificate_type__c to distinguish participation certificates from skill certificates.