Migrate from RippleHire to BambooHR

RippleHire Jobs map to BambooHR Job Openings with status, department, and location preserved. BambooHR Core caps active job openings at 5; Core+ATS raises this to 25; Elite supports 50. We flag any migration scope exceeding the destination tier's job-opening limit and recommend a tier upgrade before or shortly after migration. Job board posting attribution and sourcing channel tags from RippleHire migrate as custom fields on the BambooHR Job Opening.

RippleHire Candidates who are still in the hiring pipeline migrate to BambooHR Applicants. Those with a completed offer migrate to BambooHR Employee records via the onboarding Add Employee flow. We preserve stage progression timestamps, candidate contact details, and any sourcing channel attribution (referral, vendor, job board) as custom fields on the BambooHR record. RippleHire's candidate status history migrates as a note attachment on the record for audit.

RippleHire referral records include referrer identity, referral status, and reward eligibility data that has no native equivalent in BambooHR. We extract the full referral record and map referrer identity to a BambooHR employee custom field (e.g., referral_referrer_name, referral_status, referral_reward_eligible). Any gamification-specific fields such as reward payout status and incentive tier do not map to standard BambooHR fields and are flagged in a written reconciliation document for manual post-migration processing.

RippleHire offer records migrate to BambooHR Job Offers with offer amount, start date, position title, and acceptance or decline status preserved. The multi-level maker-checker approval chain outcomes (who approved, at which stage, under which policy rule) migrate as date-stamped notes on the offer record. The approval routing logic itself is system-specific and does not migrate; we document the approval chain as a written record for the customer's HR admin to reference when rebuilding offer approval routing in BambooHR's standard approval workflow configuration.

RippleHire onboarding data including post-offer engagement (POFU) status and BGV status flags migrate to BambooHR's New Hire Packet as task completion records and status flags. Day-one details (first-day schedule, equipment assignments) live in RippleHire's onboarding module and migrate as notes or custom fields on the BambooHR onboarding task list. We carry BGV verification status flags (verified, pending, failed) as custom fields; detailed BGV report documents migrate as attachments to the Employee record.

RippleHire BGV records tracking Aadhaar-based and other India-specific verification checks map to BambooHR employee custom fields (e.g., bgv_status, bgv_date, bgv_provider). Detailed BGV report documents export as file attachments to the employee record. BambooHR does not have a native India-specific BGV module; organizations requiring ongoing Aadhaar-based verification post-migration may need to maintain a third-party BGV integration.

RippleHire Users (recruiters, hiring managers, admins) map to BambooHR Employee records and receive BambooHR user access corresponding to their RippleHire role. Role-based permissions and access scopes are documented for the customer's BambooHR admin to configure in the destination system. Owner assignments on Jobs, Candidates, and Offers migrate by resolving the RippleHire user email against the BambooHR employee directory.

RippleHire custom fields on Jobs and Candidates (industry-specific picklists, conditional attributes, and workflow-specific data) map to equivalent BambooHR custom fields on Job Openings and Employee records. Any picklist or conditional-logic dependencies are flagged in a written inventory for the customer's admin to rebuild as BambooHR conditional visibility rules or custom picklists post-migration.

RippleHire unifies referral, agency/vendor, and job board sourcing under a single channel attribution model. We preserve source attribution at the candidate and offer level as custom fields on the BambooHR Applicant or Employee record (e.g., candidate_source, referral_referrer_id). Vendor-specific pipeline stages that are RippleHire-specific do not map to BambooHR's ATS and are flagged for manual reconciliation.

RippleHire maker-checker workflow configurations govern offer approvals and other approval gates as system-level workflow definitions. These are configuration artifacts rather than transactional records. We map the outcome records (who approved, when, under which policy) as date-stamped notes on the relevant Offer record. The workflow routing logic itself is not transferable to BambooHR's approval engine and is documented in a written workflow inventory for the customer's HR admin to rebuild in BambooHR's standard approval configuration.