Migrate from Occupop to BambooHR

Occupop Jobs map directly to BambooHR Job Openings, which require the ATS module to be enabled on the customer's BambooHR tier (5 openings on Core, 25 on Pro, 50 on Elite). We export Job title, description, department, location, and status (active/closed). The BambooHR Job Opening is created first so that subsequent Candidate-to-Application mapping can reference it as the parent. The original Occupop Job ID is preserved in a custom field on the Job Opening for audit traceability.

Occupop Candidates map to BambooHR Job Applications, which are linked to both a Job Opening and an Employee record. When the Candidate has no corresponding Employee in BambooHR yet (common for early-stage applicants), we create a minimal Employee record as a placeholder so that the Application has a valid parent. The Candidate's name, email, phone, and stage history migrate to the Application. If the BambooHR tier does not include the ATS module, Applications cannot be created; we flag this at scoping and confirm the customer's tier selection before migration.

Occupop Workflow Stages (Applied, Screening, Interview, Offer, etc.) per Job map to BambooHR Application Status values. We build a stage-name mapping table during scoping, preserving the stage order from Occupop. Not all Occupop stage types have BambooHR equivalents; where no match exists we map to the nearest BambooHR status (e.g., Offer stage maps to Hired, or a custom Rejected status for pipeline stages beyond the standard). The mapping is applied consistently across all Jobs at import time.

Occupop Users (Hiring Managers, Recruiters, Admins) map to BambooHR Employee records. We export name, email, and role assignment. Role mapping is configuration-only in BambooHR; permissions live in BambooHR's permission system rather than named recruiter/hiring-manager roles. We map Occupop Admin to BambooHR Full Admin permission and Occupop Hiring Manager/Recruiter to BambooHR Standard User with recruiting-specific access granted via the ATS module permissions. Users who are purely ATS users with no corresponding employee record in the HRIS get a placeholder Employee record with the ATS permission flag set.

Occupop CV file references and attachments map to BambooHR File Attachments linked to the Employee record or Job Application. We export raw CV files alongside the record mapping and deliver them as a file package. BambooHR's file attachment API supports PDF, DOC, and DOCX; we convert any non-standard format during export and flag any files that cannot be converted. The original file name is preserved in the BambooHR attachment record.

Occupop interview notes, scorecard responses, and written feedback per Candidate per stage migrate to BambooHR Notes linked to the Application or Employee record. We preserve the stage context by including the stage name in the Note title. Score values from scorecards migrate as structured text within the Note body; they do not populate a native numeric field in BambooHR since BambooHR does not have a native interview-scorecard object.

Occupop AI screening scores (0-100 values computed from CV-to-JD matching) do not have a native equivalent in BambooHR. We handle this by either creating a BambooHR Employee custom field of numeric type (if the customer's BambooHR plan supports custom fields and the field ceiling has not been reached) or by attaching a structured Note to the Application record containing the score value, rank within the candidate pool, and scoring rationale. The customer chooses the strategy at scoping. We flag that BambooHR's API has a documented per-record field ceiling that may limit the number of custom numeric fields on the Employee object.

Occupop's per-tenant custom key-value pairs on Candidate records map to BambooHR Employee custom fields. We inspect the source tenant's custom field definitions during scoping, build a field map, and apply it at import time. Field type mapping is direct for string, number, and date types. Occupop multi-select or tag-style custom fields map to BambooHR multiselect custom fields. We flag any custom fields that exceed the BambooHR API field ceiling (approximately 400 fields per Employee record) and fall back to storing them as structured JSON in a single text field or as attached notes for those records.

Occupop tracks which job boards a Job was distributed to (Indeed, LinkedIn, Reed, Glassdoor, niche boards) and the posting date. BambooHR has no native board-distribution tracking field. We export this as a structured list per Job and attach it as a Note to the Job Opening. We deliver a board-distribution summary sheet post-migration listing each Job, its original distribution channels, and dates so that the customer's recruiting team can manually re-create postings in BambooHR's job board distribution UI or via each board's native posting tool.

Offer letters, employment contracts, and onboarding workflow state are not accessible via Occupop's ATS export. Post-acquisition these records live in Cezanne HR's broader suite, not in Occupop's ATS data model. We explicitly exclude offer and onboarding records from migration scope and direct the customer to export them from Cezanne HR directly before initiating the migration. If the customer does not have Cezanne HR access, we recommend they contact Occupop support to retrieve offer and onboarding data before the migration window closes.