Migrate from ApplicantStack to BambooHR

ApplicantStack Positions map directly to BambooHR Job records. We extract job title, description, status (open, closed, archived), job board distribution settings (as content only), and opening count. BambooHR enforces a job opening limit by plan tier (Core: 5, Pro: 25, Elite: 50) which we confirm during scoping. If the customer's active job count exceeds the target tier, we flag the discrepancy and recommend a plan upgrade before migration. Job board distribution settings do not migrate as configurations; the job description content migrates as content and the customer republishes to the desired boards in BambooHR.

ApplicantStack Candidate records map to BambooHR Application records linked to a Job. We extract name, contact information (email, phone, address), application date, resume file, current pipeline stage, source attribution, notes, and custom property responses. ApplicantStack's unreliable duplicate detection means we run dedup logic during transformation matching by email address, normalized name, and phone number. Likely duplicates are flagged for customer review before final import to prevent multiplying duplicate applications in BambooHR.

ApplicantStack Questionnaire responses are stored as field-value pairs on the Candidate record. We extract all custom field responses and map them to custom fields on the BambooHR Application object. If the destination custom fields do not exist, we create them during the schema setup phase using BambooHR's custom field API. Dropdown, checkbox, and rating question types map to the corresponding BambooHR field types. The customer reviews the field mapping during sandbox validation to confirm that questionnaire logic maps correctly into BambooHR's application data model.

ApplicantStack pipeline stages (Applied, Screening, Interview, Offer, Hired, Rejected) and any custom stages configured by the customer map to BambooHR Application Stage values. We export the full pipeline configuration including stage names, ordering, and any custom stage properties. BambooHR's ATS uses a predefined stage model; we map each ApplicantStack stage to the nearest BambooHR equivalent and document any stages that cannot map directly for the customer's admin to resolve in BambooHR's settings post-migration.

ApplicantStack user roles (Administrator, Recruiter, Hiring Manager) control access to jobs and candidates. We export role assignments and map them to BambooHR Employee records for hiring team members. BambooHR's ATS uses the standard Employee object for hiring team assignment rather than a separate user object. Email address is the matching key. Any ApplicantStack user without a corresponding BambooHR Employee record goes to a reconciliation queue for the customer's admin to provision before candidate assignment migration proceeds.

When ApplicantStack Onboard is active, new hire onboarding packets include I-9 data, tax form acknowledgments, and custom onboarding documents. We extract these as structured records and separate document blobs. I-9 and tax form data migrate as BambooHR Employee custom fields or document attachments; onboarding task checklists migrate as BambooHR Onboarding Task records. The separation between ApplicantStack Recruit (candidate data) and ApplicantStack Onboard (new hire data) requires confirming which SKU is active during discovery to calibrate scope and avoid over-estimating available data.

Resume files, cover letters, and uploaded documents extract from ApplicantStack candidate records as binary blobs. We preserve file names and attach them to the corresponding BambooHR Application record using BambooHR's file attachment API. File type, original file name, and upload timestamp are preserved in the attachment metadata. If the candidate record has no resume on file, we migrate a placeholder note indicating no resume was attached in ApplicantStack.

ApplicantStack stores email templates used in candidate communication sequences. We export template content and map variable placeholders to a reference document. The automated trigger logic, send conditions, and timing sequences do not migrate as code. BambooHR's ATS includes email and offer letter templates; we provide the customer with a template content inventory mapped to the closest BambooHR equivalent so the admin can rebuild communication sequences in BambooHR's workflow builder.

Custom properties added to Candidates or Jobs beyond ApplicantStack's standard schema are captured as key-value pairs. We map them to custom fields on the corresponding BambooHR object during schema setup, creating the destination properties via BambooHR's API before import begins. Field type mapping follows the nearest equivalent: ApplicantStack text fields become BambooHR text fields, dropdown fields become option lists, and numeric fields become number fields. Multi-select custom properties in ApplicantStack map to multi-select picklists in BambooHR.

Candidate tags and job labels export from ApplicantStack as flat tag arrays. We preserve all tags and apply them to the corresponding Application records in BambooHR. Tag merge logic handles cases where identical tags exist under slightly different names in the source data. BambooHR's tag model supports tagging applications by keyword; the customer can use tags to replicate ApplicantStack's label-based filtering workflows.