Migrate from RippleHire to Bullhorn ATS & CRM

RippleHire Jobs (requisitions) map directly to Bullhorn JobOrder. JobOrder.title, description, and address map from RippleHire job name, description, and location. We preserve the sourcing channel attribution (referral, agency, job board) as a custom field sourcing_channel__c since Bullhorn's standard jobOrder does not have a dedicated sourcing attribution field. Job board posting status and external job ID migrate as Bullhorn custom fields if the customer has configured them in RippleHire.

RippleHire Candidate records map to Bullhorn Candidate by firstName, lastName, and email. RippleHire's candidate status (applied, screening, interview, offer, hired, rejected) maps to Bullhorn's candidateStatus field values. Stage progression timestamps migrate as Bullhorn dateCustomText fields; if the customer requires a full pipeline stage history, we create a Bullhorn custom object with stage-name and timestamp columns per candidate.

RippleHire Referral records attach to a Candidate and carry the referrer identity, referral status, and reward eligibility fields in a proprietary gamification schema. We extract the full referral record including reward_eligible, reward_status, referral_bonus_amount, and referrer_name fields and map them to Bullhorn Candidate custom fields (referral_referrer__c, referral_status__c, referral_bonus__c, referral_reward_eligible__c). Bullhorn's Front Office Growth or Enterprise tier supports up to 10 custom objects with 55 fields each, enough to hold the referral reward schema. ATS Growth tier has no custom objects and cannot natively store gamified referral data; we flag this constraint during scoping.

RippleHire Offer records map to Bullhorn Opportunity as the closest equivalent. RippleHire offer fields (offered_salary, offer_status, offered_position, joining_date) map to Opportunity.amount, custom opportunity fields, title, and a date field. The Bullhorn Placement object is created from the Opportunity after migration if the offer is accepted. Offer acceptance or decline status migrates as a custom opportunity field; Bullhorn does not have a native offer acceptance workflow so the outcome is recorded as a note on the Opportunity.

RippleHire's maker-checker approval workflow captures who approved an offer, at which stage, and under which policy rule. These approval-chain records carry meaningful audit context but do not map to Bullhorn Opportunity fields. We carry the approval chain as Bullhorn Note records attached to the Opportunity, with note.title set to 'Offer Approval: [Stage]' and note.body containing the approver name, timestamp, and policy rule. Bullhorn Automation or Bullhorn Canvas is used post-migration to rebuild the approval routing logic.

RippleHire BGV records store verification status against Aadhaar and other India-specific checks tied to Candidates. Bullhorn has no native BGV object, so we create a Bullhorn custom object bgv_status__c with fields for verification_provider__c, bgv_status__c, aadhaar_verified__c, bgv_completion_date__c, and bgv_report_url__c. The Bullhorn custom object limit (10 on Front Office Growth/Enterprise, 2 on Bullhorn ATS) governs whether the full BGV schema fits natively or requires a third-party BGV integration partner.

RippleHire Onboarding records (post-offer engagement, BGV completion, day-one scheduling) map to Bullhorn Placement with custom fields capturing onboarding_status__c, day_one_start_date__c, and task_completion_flags. RippleHire's onboarding task list is not a migratable object; we deliver a written inventory of onboarding tasks and their completion status as Bullhorn custom fields or a Bullhorn Placement custom object, and the customer rebuilds the onboarding workflow in Bullhorn's onboarding module or Bullhorn Canvas.

RippleHire Users (recruiters, hiring managers, admins with role-based access) map to Bullhorn User by email address. Role-based permissions from RippleHire (recruiter, hiring_manager, admin) map to Bullhorn User role and permissions if the customer's Bullhorn edition supports granular role configuration. Bullhorn User must be provisioned in the destination org before any record import; we reconcile RippleHire owners against Bullhorn Users during the owner reconciliation step and flag missing Users for the customer's Bullhorn admin to create before record migration begins.

RippleHire supports custom fields on Jobs and Candidates for industry-specific attributes. We map these to Bullhorn custom fields on JobOrder and Candidate respectively, with field type mapping (RippleHire text to Bullhorn text, picklist to Bullhorn DDL, date to Bullhorn date). Picklist value dependencies from RippleHire map to Bullhorn DDL values; any conditional-logic dependencies that cannot be enforced through Bullhorn field-level rules are flagged as post-migration admin tasks. Bullhorn's field edit-type limits (up to 20 checkboxes/dropdowns/radios per custom object) apply if custom fields are housed in a Bullhorn custom object.

RippleHire unifies referrals, vendor/agency, and job board sources under a single sourcing attribution per Candidate. Bullhorn's standard Candidate object does not have a dedicated sourcing channel field. We preserve source attribution by creating a Bullhorn Candidate custom field sourcing_channel__c and populating it from RippleHire's source field (referral, agency, jobboard, direct, internal). Vendor-specific pipeline stages may require a Bullhorn ClientCorporation record to represent the agency as a client in Bullhorn.

RippleHire's Decline Analysis is an aggregated reporting artifact summarizing offer decline trends across the hiring pipeline. It is not a transactional data record and has no migratable data rows. We exclude it from migration scope and flag it as a reporting gap: the customer's Bullhorn admin rebuilds decline analysis as a Bullhorn Analytics report or an external BI dashboard using Bullhorn Opportunity data post-migration.

RippleHire shared dashboards (offer status, pipeline analytics, decline insights) are BI-layer artifacts tied to RippleHire's data warehouse and do not export as structured data records. We exclude them from migration scope. We deliver a written catalog of the dashboards with their metric definitions and filter logic for the customer's Bullhorn admin to rebuild in Bullhorn Analytics or connect to an external BI tool (Tableau, Power BI, Metabase).