Migrate from Beamery to Bullhorn ATS & CRM

Beamery Contacts (candidates) map 1:1 to Bullhorn Candidate records. Standard fields (name, email, phone, address) map directly. Beamery custom fields on Contact migrate to Bullhorn Candidate custom fields, which are scoped to a maximum of 55 fields per Custom Object and constrained by the customer's Bullhorn edition tier. We discover the Bullhorn field schema via the API before import and map Beamery multi-value fields (semicolon-delimited in Beamery CSV exports) to Bullhorn multi-select or text fields depending on the target field type.

Beamery Talent Pools have no native Bullhorn equivalent. Bullhorn uses Candidate Groups (named collections created manually or via list-building) and Saved Searches to approximate pool-based segmentation. We export pool membership and membership-date metadata from Beamery, then recreate groups in Bullhorn by generating Candidate Group records and populating them with the matching candidate IDs. The original pool membership date is stored as a custom date field on the Candidate record for audit traceability.

Beamery Vacancies map to Bullhorn Job records. The vacancy title, description, status, and assigned recruiter migrate. Beamery's vacancy pipeline stages (which vary by tenant configuration) map to Bullhorn's Job Order Status values — typically: Open, Interviewing, Offer, Placed, Cancelled. We document the source stage names during scoping and provide a stage-mapping table for Bullhorn configuration before migration. Vacancies without a status field default to Open in Bullhorn.

Beamery's configurable stage pipelines per Vacancy do not map directly to Bullhorn's single Job pipeline. We map each Beamery pipeline stage to a corresponding Bullhorn Job Order Status and optionally configure Bullhorn's Job Order Track (a Bullhorn ATS/Enterprise feature) to approximate the multi-stage pipeline structure. The customer selects the target track during scoping; we configure the stage values before Job import begins.

Beamery Campaigns (outbound engagement sequences) map partially to Bullhorn. Campaign membership and send-event metadata migrate to Bullhorn as a Candidate List plus associated Task records tracking outreach history. The automation recipe driving the campaign — triggers, conditional assignments, send cadence — does not migrate; we document the active campaign configurations for manual rebuild in Bullhorn Automation or Bullhorn Workflows. Candidate email opt-in status from the campaign migrates to Bullhorn's HasOptedOutOfEmail field.

Beamery's skills taxonomy (customer-defined, attached to Contacts) translates to Bullhorn Tags. We export all skill taxonomy entries as flat text values, deduplicate the taxonomy across the dataset, and bulk-create Bullhorn Tags. Each Contact's skill assignments become Tag records linked via TagAssignment. The mapping is lossy in the sense that Bullhorn Tags lack the hierarchical taxonomy relationship that Beamery's Skills Intelligence provides — we flag this explicitly and the customer decides whether to preserve a flat tag structure or build a custom taxonomy object in Bullhorn.

Beamery Users (recruiters and sourcers) map to Bullhorn Users. We resolve by email address match. Bullhorn User provisioning requires the customer's Bullhorn admin to create the User record before migration; we provide the resolved user list and flag any Beamery User without an email match for manual provisioning. Role names and permission levels differ between platforms — we document the source role assignments as a separate role-mapping table for the Bullhorn admin to configure post-migration.

Beamery engagement events (emails sent, page views, calls, notes) migrate as Bullhorn Task records linked to the Candidate. Email engagements become Task records with email body content; call engagements become Task records with Call disposition in the Task description or a custom field; notes become Bullhorn Notes linked via ContentDocumentLink to the Candidate. Activity timestamp (ActivityDate) preserves the original Beamery engagement date for timeline continuity. Large engagement histories (over 50,000 records) are chunked and loaded via Bullhorn's REST API with rate-limit handling and exponential backoff.

Beamery flat tags on Contacts migrate 1:1 to Bullhorn Tags. The tag label is preserved exactly as exported from Beamery. Tag migration is straightforward because both platforms use a flat label model for this object type.

Beamery Convert Flow form submissions — the field values submitted when a candidate applies via a Beamery-hosted form — migrate as Candidate records with the original form field values mapped to corresponding Bullhorn Candidate custom fields. The Convert Flow configuration itself (form layout, conditional logic, post-submit automation) does not migrate and must be rebuilt as a Bullhorn career portal form or third-party intake tool. We document the form schema during scoping.

Beamery custom fields on Contacts and other objects are discovered via the API before export. We map each to a Bullhorn Candidate custom field, verifying field type compatibility (text, number, date, picklist, multi-select). Bullhorn caps custom fields at 55 per entity type on Bullhorn ATS editions; Front Office Growth/Enterprise supports up to 10 custom objects with 55 fields each. If the Beamery custom field count exceeds the Bullhorn edition limit, we flag this during scoping and the customer decides which fields to prioritise.

Binary attachments on Beamery Contacts (resumes, portfolio files) are stored as URLs in Beamery. We export the file reference URL and metadata. If the file storage is accessible via Beamery's API, we retrieve the binary and upload it to Bullhorn as a Candidate Document. Bullhorn's resume parsing runs on import of text-based resumes (PDF, DOCX, RTF). We cannot guarantee parsing quality for resumes imported as binary attachments from Beamery if the original file format is not supported by Bullhorn's parser.