Migrate from Cadient to BambooHR

Cadient Candidates map to BambooHR Applicants when the candidate is still in the hiring pipeline, and to BambooHR Employees when a hire record exists. We inspect the Candidate record's status field to determine the split. Active candidates with pending applications become BambooHR Applicants attached to the corresponding Job. Hired candidates become BambooHR Employees with hireDate set to the application close date. We preserve the original Cadient Candidate ID as a custom field cadient_candidate_id__c for cross-reference.

Cadient Requisitions map to BambooHR Jobs. Requisition metadata (title, department, location, open date, hiring manager) maps to BambooHR Job fields. Cadient's requisition status (open, filled, cancelled, on hold) maps to BambooHR Job status. BambooHR Jobs are scoped per Job Opening rather than per department in some configurations; we consolidate by job ID to avoid duplicate Job records for the same requisition.

Cadient Application records map to BambooHR Application records linked to the corresponding Applicant and Job. Apply date, source, referral information, and application status migrate directly. Custom application properties are reviewed during scoping; any that do not map to BambooHR standard fields become custom fields on the Application object.

Cadient Scorecard responses follow a structured question-and-answer format tied to a reviewer. We preserve the full response history as Application Notes in BambooHR, tagged with reviewer name and date. Scorecard aggregate values (SmartScore) migrate as a numeric custom field scorecard_composite__c. The component-level scorecard breakdowns (screening score, reference score, tenure prediction contribution) do not separate cleanly in the export; we document the composite value and flag that component-level reconstruction is not in scope.

Cadient Interview records (interviewer, date/time, type, disposition status) map to Application Notes in BambooHR when the ATS module does not expose a native scheduling object. Interview type (phone, video, onsite) and outcome (passed, failed, no-show) are preserved as structured note metadata. We document interview scheduling and calendar integration setup post-migration for BambooHR's native scheduling or a third-party tool.

Cadient SmartScore is a composite signal synthesized from screening, references, and tenure prediction. The composite numeric value migrates as a custom field (cadient_smartscore__c) on the BambooHR Applicant. The component-level breakdowns are not separately exported from Cadient, so we cannot reconstruct the individual signal weights in BambooHR. We flag this as informational data that should not be used as the sole hiring criterion without re-scoring in BambooHR or a third-party assessment tool.

SmartTenure generates a stay-risk score using a proprietary ML model with non-exposed weights and training data. We migrate the numeric score as a custom field (cadient_tenure_score__c) on the Applicant with an explicit note that this is a static value from the Cadient model and cannot be reproduced in BambooHR. Destination scoring requires re-running a BambooHR-compatible model on the transferred candidate data, which is outside the migration scope.

Cadient offer letter templates and issued offer records can be exported as documents. In BambooHR, offer letters are typically stored as file attachments on the Application or Employee record. We migrate the most recent offer document per candidate as an attachment. The offer status (accepted, pending, declined) migrates as a custom picklist field on the Application because BambooHR does not expose offer status as a standard application sub-field.

Cadient SmartRefer tracks referral sources as structured fields on the Application. We map the referral source to BambooHR's Application source field (with values like Employee Referral, LinkedIn, Job Board) and preserve the specific referring employee name as a custom field if available.

Cadient custom fields on Candidate records migrate to BambooHR custom fields on the Applicant object. BambooHR requires fetching field IDs via GET /v1/meta/fields per tenant before creating or populating custom fields, as field IDs are unique per account. We discover custom field IDs during scoping and use them in the migration script. Any Cadient custom fields without a BambooHR equivalent are documented as unmapped for the customer to address post-migration.

Assessment results depend on the screening tool Cadient integrates with (AccurateNow, Paycor, or other). We migrate raw assessment scores as custom numeric fields on the BambooHR Application. We flag any assessments that require re-scoring through a different provider and document the assessment tool dependencies for the customer's HR team to re-establish post-migration.

Cadient hiring workflow stages, routing rules, and automated triggers do not export as structured data. We capture the current stage definitions during discovery and produce a written stage map that the customer's admin uses to configure BambooHR's hiring pipeline stages. BambooHR automations (time-off approvals, onboarding task triggers) are configured separately post-migration. We do not migrate workflow logic as executable code.