Migrate from Employ to BambooHR

Employ Job records map to BambooHR Job Opening with title, description, department, location, and status preserved. The Employ job ID is retained in a custom field emp_job_id__c for reconciliation. BambooHR's Job Opening is the ATS-side record that candidates apply to; post-hire, the job context is linked to the Employee but BambooHR does not maintain a formal job history object. Active jobs migrate as open; closed jobs migrate as closed with application counts preserved.

Employ Candidate records map to BambooHR Applicant records. Contact information (name, email, phone, address), work history, education, and skills transfer directly. AI interview scores are stored as metadata on the Employ Candidate and require extraction as structured fields; we write these to BambooHR custom fields (created pre-migration) named ai_interview_score__c, ai_screening_status__c, and ai_confidence_rating__c if the customer wants to preserve them. Any Candidate without an associated Application in the migration scope is still migrated as an Applicant to preserve the talent pool.

Employ Application records represent the candidacy link between a Candidate and a Job, carrying pipeline stage, application date, source, and any notes. In BambooHR's flat applicant model, this candidacy is represented by the Applicant record itself being attached to a Job Opening. We preserve the application date as a custom field app_submitted_date__c, the source as app_source__c, and notes in the BambooHR applicant notes field. Stage history from Employ is preserved as a custom field pipeline_history__c in JSON format if the customer requests it.

Employ allows each customer to define custom pipeline stages per job with no standard schema. BambooHR uses a fixed stage list per job type (Applied, Phone Screen, Interview, Offer, Hired, Rejected) with limited customization. We extract the full Employ stage list during discovery, map each to the closest BambooHR equivalent, and flag any stages with no valid mapping for the customer's admin to assign manually before migration. Stages with no equivalent land in a custom field original_stage__c on the BambooHR applicant record.

Employ AI Recruiter evaluation scores are not a standalone exportable object; they are stored as metadata on the Candidate record. We identify candidates with AI scores during data audit, extract the structured score values and confidence ratings, and write them to pre-created BambooHR custom fields. The extraction logic uses custom parsing since there is no documented API field name. We flag any score that maps to a rating above or below the destination custom field's defined range and scale the values to fit.

When a Candidate is hired, the record transitions to an Employee object in Employ with start date, department, manager, employment status, and compensation fields. We map these directly to BambooHR Employee fields. The Employee is created in BambooHR during the post-hire migration phase after the Applicant record has been confirmed as hired. Manager relationships are resolved via email match against the BambooHR destination's user directory; any manager without a matching Employee record is flagged in reconciliation.

Employment eligibility verification records are regulatory documents that must transfer with their full audit trail intact. We carry I-9 and E-Verify records as encrypted file attachments linked to the corresponding Employee record in BambooHR. We do not re-trigger the E-Verify workflow in BambooHR because that would overwrite the existing verification status. The customer must confirm before migration that BambooHR's file storage policy meets their compliance retention requirements. Some BambooHR configurations require the HR admin to re-upload I-9 documents manually post-migration; we document this decision during scoping.

Employ assigns Users to roles (Recruiter, Hiring Manager, Admin) tied to hiring permissions. BambooHR uses an Employee record with an Employee Type field (Full-Time, Part-Time, Contractor) and access-level configuration. We extract role assignments and map them to BambooHR employee type and a custom role field emp_source_role__c for reference. BambooHR's permission model is role-based (Employee, Manager, Admin) and controlled separately from the employee record. Any Employ user who is not also an Employee (e.g., external recruiter) is flagged as a non-employee user for manual provisioning in BambooHR.

Employ supports custom fields on Jobs, Candidates, and Applications. BambooHR supports custom fields on Employee, Applicant, and Job Opening objects. We conduct a custom field audit during discovery (there is no published schema documenting which custom fields exist per customer), create matching custom fields in BambooHR pre-migration, and map the values during the load phase. Custom fields with unsupported data types (e.g., complex nested objects) are flagged for the customer's admin to resolve.

Job postings distributed to third-party job boards are tracked as configuration settings in Employ rather than as data records. These are destination-specific and tied to Employ's job board integration partnerships. We do not migrate these configurations. The customer's admin rebuilds job distribution settings in BambooHR's job board integrations (Indeed, Glassdoor, LinkedIn) or their existing job board accounts post-migration.