Migrate from Kula to BambooHR

Kula Candidate records map to BambooHR Employee records in pre-hire status for candidates who advance to offer and acceptance. Candidate contact information (name, email, phone, address) maps to the corresponding BambooHR Employee fields. Active sourcing profile data from LinkedIn and GitHub preserved in custom fields or note attachments since BambooHR does not have native sourcing profile fields. We flag AI-generated candidate scores from Kula as read-only custom text fields on the BambooHR Employee record; these are static values and will not update automatically.

Kula Job records map to BambooHR Job Openings (ATS module, Advantage tier required). We extract the job title, department assignment, location, employment type, and description, then map them to BambooHR's job opening fields. Pipeline stages from Kula extract as custom pipeline status values in BambooHR; we create the status options during schema setup to match Kula's stage ordering. Active versus closed status preserves at migration time. Jobs without a department match in BambooHR are flagged for the customer admin to configure departments before migration.

Kula Application records (linking a Candidate to a Job with stage progression history) map to BambooHR Applicant records. Source attribution (referral, job board, direct) migrates to BambooHR's applicant source field. Application submission date, current pipeline stage, and outcome (rejected, withdrawn, offer extended, offer accepted) transfer as structured fields and custom fields where BambooHR's native schema does not cover the outcome states. We preserve stage progression timestamps as note attachments for audit continuity.

Kula Interview records map to BambooHR Interview records for candidates who have reached the interview stage in the BambooHR ATS pipeline. Interviewer assignments resolve by email match against BambooHR user records. Scheduled round, date, and outcome data transfers to the BambooHR interview record. If the destination BambooHR account does not have ATS enabled (Essentials tier), interviews migrate as note attachments on the applicant record rather than native interview objects.

Kula Scorecard records with reviewer ratings and evaluator feedback map to BambooHR Note records attached to the relevant applicant. Scorecard templates do not transfer as reusable templates; we document the template structure (rating dimensions, scoring scale) in the handoff inventory so the customer's admin can recreate templates in BambooHR's form builder. AI-generated interview summaries from Kula migrate as text note content, not as live metrics, since BambooHR has no equivalent AI summarization feature.

Kula's customizable pipeline stages per job extract as a list of stage names and ordering from the source instance. We create matching pipeline status values in BambooHR's ATS configuration during schema setup. If Kula has stages with no BambooHR equivalent (e.g., 'Assessment' or 'Culture Fit' stages without a direct BambooHR status), we map them to the nearest equivalent and flag the gap in the handoff documentation. Stage probabilities from Kula do not transfer to BambooHR because BambooHR ATS does not use probability-based pipeline forecasting.

Kula custom fields on Candidates, Jobs, or Applications extract as definitions and values. We map them to BambooHR custom fields, creating new custom fields in BambooHR during pre-migration setup. Note that BambooHR API cannot pass dropdown list fields with values that do not match existing picklist options; we validate picklist values against BambooHR's allowed values during mapping and flag mismatches. Custom fields with multiple-selection behavior require conversion to multiple single-select fields or custom text fields in BambooHR because native multi-select is not fully supported via API.

Kula tags (e.g., 'referral', 'sourced-linkedin', 'passive-candidate') migrate to BambooHR custom fields or text fields on the applicant record. Source attribution from applications (where the candidate was sourced) migrates to the native applicant source field. Tag limits in BambooHR require validation during mapping; we flag any tag that cannot map directly and propose a custom field alternative. Tags used for candidate classification rather than sourcing map as custom text properties with the original tag preserved in the field value.

Recruiter owners, hiring managers, and interviewers from Kula resolve by email match against BambooHR User accounts. We extract every distinct user referenced in Kula job and application assignments, cross-reference against the BambooHR user table, and flag any Kula user without a matching BambooHR user in a reconciliation queue. The customer's BambooHR admin provisions any missing users before record migration resumes. Orphaned assignments (where the user does not exist in BambooHR) default to the admin user and are flagged for manual reassignment post-migration.

Kula's interviewer pool membership records map to BambooHR User Groups. Pool membership assignments migrate as group memberships in BambooHR. Availability settings and scheduling rules are destination-dependent and do not transfer; we document the original pool structure and availability rules in the handoff inventory for the customer's admin to reconfigure in BambooHR's scheduling module. Scheduling load balancing requires manual setup in BambooHR post-migration.