Migrate from Alongside to Bullhorn ATS & CRM

Alongside candidate records map to Bullhorn Candidate. We inspect the customer's Alongside export to identify which fields correspond to Candidate.firstName, Candidate.lastName, Candidate.email, Candidate.phone, Candidate.address, Candidate.education, and Candidate.employmentHistory. Historical status values from Alongside (active, placed, archived) map to Bullhorn Candidate.status. Resume files migrate as CandidateResume attached via ContentDocumentLink. If Alongside stores candidate skills or certifications as custom fields with no standard Bullhorn equivalent, we flag them for Bullhorn Custom Object creation (subject to edition tier limits: 10 for Front Office Growth/Enterprise, 2 for Bullhorn ATS, none for ATS Growth).

Alongside client or company records map to Bullhorn ClientCorporation. We extract company name, address, industry, phone, website, and revenue tier from the Alongside export and map them to the corresponding Bullhorn ClientCorporation fields. ClientCorporation is created before any ClientContact or JobOrder import so that the lookup relationship is satisfied at insert time. Any Alongside-specific fields without a Bullhorn standard equivalent are flagged for custom field or Custom Object placement.

Alongside contact records attached to a client map to Bullhorn ClientContact, linked via ClientCorporationID. We extract name, email, phone, title, and department from the Alongside export and resolve the parent ClientCorporation by company name match. If Alongside does not enforce a strict client-contact hierarchy and contacts are flat, we create a default ClientCorporation record for orphaned ClientContacts or, if the customer prefers, map them directly to Candidate if they represent contractor contacts.

Alongside job or position records map to Bullhorn JobOrder. We extract title, description, requirements, location, employment type (full-time, contract, part-time), pay range, and status (open, filled, closed) from the Alongside export. JobOrder is inserted after ClientCorporation and before any CandidateJobApplication or Placement, satisfying the ClientCorporationID and OwnerID references. Status values from Alongside map to Bullhorn JobOrder.status.

Alongside application or submission records linking a Candidate to a Job map to Bullhorn JobSubmission. The mapping resolves CandidateID and JobOrderID by email match and job title match respectively. Submission date, status (applied, screening, interview, offer, hired, rejected), and source (referral, job board, direct) migrate from Alongside. If Alongside stores rejection reason or interview feedback as custom fields, these map to JobSubmission custom fields or notes attached to the submission.

Alongside placement records (a Candidate placed into a Job at a Client) map to Bullhorn Placement. The mapping resolves CandidateID, JobOrderID, and ClientCorporationID at migration time. Placement startDate, endDate, payRate, billRate, and status (active, completed, terminated) migrate directly. If Alongside stores onboarding documents or contract references as attachments, these migrate as ContentDocumentLink records attached to the Placement.

If Alongside stores deal or opportunity records tied to a ClientCorporation (e.g., a staffing firm's commercial pipeline separate from placed jobs), these map to Bullhorn Opportunity. The mapping resolves ClientCorporationID, OwnerID, and Opportunity amount. Stage values from Alongside map to Bullhorn Opportunity.stageName, with Salesforce Record Types and Sales Processes configured if the customer uses multiple deal pipelines. This object is optional depending on Alongside schema scope.

Alongside call records map to Bullhorn Task with TaskSubtype=Call. We extract call date, duration, disposition (if stored), and outcome from the Alongside export and set Task.ActivityDate, Task.CallDurationInSeconds, and Task.Description. The Task WhoId points to the resolved Candidate or ClientContact. Call recording URLs migrate to custom Task fields. Activity ordering is preserved by setting ActivityDate to the original Alongside timestamp.

Alongside email engagement records map to Bullhorn EmailMessage (the content) linked to an Activity Task record (the timeline entry). The email body, subject, from, to, and cc fields migrate to EmailMessage. The Task WhoId links to the Candidate or ClientContact; the WhatId links to the related JobOrder, Placement, or ClientCorporation. If Alongside stores email threads as flat records without thread IDs, we preserve the conversation context by ordering EmailMessages by timestamp.

Alongside meeting records map to Bullhorn Event. We extract startDateTime, endDateTime, location, title, and description from the Alongside export. Attendee resolution links to EventRelation records pointing at the migrated Candidates, ClientContacts, and Users. Recurring meeting series from Alongside are flagged as a known limitation: we can migrate individual Event instances but series recurrence rules require Bullhorn calendar rebuild post-migration.

Alongside notes attached to Candidates, Jobs, or Companies map to Bullhorn Note records linked via ContentDocumentLink to the parent record. Note body migrates as plain text or rich text depending on formatting detected in the Alongside export. If Alongside stores notes with author and timestamp metadata, these map to Note.Title and Note.Body. File attachments embedded in notes migrate as separate ContentDocument records attached to the Note.

Alongside task records map to Bullhorn Task with Status, Priority, Subject, and ActivityDate preserved. Task assignment resolves the Alongside assigned user to a Bullhorn User by email match. Recurring tasks from Alongside are flagged as a Bullhorn limitation: Bullhorn does not natively support recurring task series, so recurring Alongside tasks are migrated as individual Task records with a custom field indicating the original recurrence pattern for manual rebuild in Bullhorn.

Alongside custom entities or fields without standard object equivalents migrate to Bullhorn Custom Objects. We first establish which Alongside fields are custom versus standard by inspecting the export. Bullhorn requires a Support ticket with a completed Custom Object Setup Spreadsheet to provision each Custom Object before REST API access. Each Bullhorn Custom Object supports 55 fields across a limited set of edit types (text, dropdown, checkbox, picker). We coordinate this provisioning step with Bullhorn Support as part of discovery and map each Alongside custom entity to its corresponding Bullhorn Custom Object API name.

Alongside uploaded documents (resumes, contracts, onboarding forms, job descriptions) migrate as Bullhorn ContentVersion records linked via ContentDocumentLink to the parent entity (Candidate, JobOrder, Placement, ClientCorporation). We extract file name, MIME type, size, and content blob from the Alongside export. ContentVersion.Title maps to the original file name. We do not migrate document version history beyond the current version in a single migration run.

Alongside tags or labels stored as multi-value fields migrate to Bullhorn multi-select picklist fields on the relevant entity. If Alongside uses tags for content classification (e.g., skill tags on Candidate), we create a custom Candidate skill_tag__c multi-select field with the Alongside tag values as picklist options. The customer chooses whether to normalize tag values (deduplicate similar tags) or preserve them verbatim during scoping.

Alongside user or employee records that represent recruiter accounts map to Bullhorn User. We resolve each Alongside user by email match against the Bullhorn destination User table. Owners referenced on Candidate, JobOrder, Placement, and Opportunity records use this User resolution. Users without a matching Bullhorn account go to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes.

Alongside's candidate pipeline stages (if structured as a workflow rather than a flat status field) map to Bullhorn's Candidate status values or to a Bullhorn custom pipeline workflow. Bullhorn's standard Candidate object uses a status field with values like 'New Lead', 'Contacted', 'Interview', 'Offer Extended', 'Hired', 'Not Qualified'. We compare Alongside's stage names against Bullhorn's standard values and recommend a status mapping, flagging any Alongside stages that require custom field or Custom Object representation.

If Alongside stores billing or invoice records tied to Placements (e.g., timesheet summaries, commission calculations, invoiced amounts), we map these to Bullhorn Placement billing fields (Placement.payRate, Placement.billRate, Placement.durationWeeks) where available. Additional billing records without a Bullhorn standard field map to a Bullhorn Custom Object for invoicing, or are exported as a CSV inventory for the customer's finance team to reconcile post-migration. This decision is made during scoping based on Alongside's actual billing schema.