Migrate from Nextal to Bullhorn ATS & CRM

Nextal Candidate records map to Bullhorn Candidate. We extract name fields, contact details (email, phone, address), source attribution (LinkedIn URL, Indeed attribution, direct application tag), and current status. Resume attachments migrate as CandidateDocument records linked to the Candidate. Any Nextal custom fields on Candidate are mapped to Bullhorn custom Candidate fields created before migration. We preserve the original Nextal candidate ID in a custom field nextal_candidate_id__c for audit and reconciliation.

Nextal Job postings map to Bullhorn JobOrder. We extract title, description, department, location, employment type, status (open/closed/draft), and job board distribution flags. Bullhorn JobOrder also carries a status workflow (New, Open, Pending, etc.) that we configure to match the Nextal job stage semantics. If the Nextal job has multilingual content, we extract the primary-language version as the Bullhorn description and flag the secondary-language content for the customer's admin to populate inside Bullhorn.

Nextal Application records link a Candidate to a Job and carry stage history. We split each Application into a Bullhorn JobSubmission record (linking Candidate and JobOrder) plus a custom field candidate_stage__c holding the final Nextal stage name. Bullhorn does not have a native stage-history object for applications; we create a Note or custom object record per Application capturing the stage transition log if Nextal exposes it in the export. Any Application with status = hired maps to a Bullhorn Placement in a separate phase after JobSubmission migration.

Nextal Kanban pipeline stages are configurable per organization. We extract the customer's stage configuration (stage name, order, color if exposed) from the Nextal export and map each to a Bullhorn JobSubmission status value plus a custom picklist field nextal_stage__c. The mapping table is customer-reviewed before migration to ensure stage semantics are preserved. Bullhorn's default JobSubmission statuses (New, Interviewing, Offer, etc.) are aligned to the Nextal stage names during configuration.

Nextal User accounts (recruiters, hiring managers, admins) map to Bullhorn User records by email address match. We extract name, email, role (recruiter, hiring manager, admin), and ownership of Jobs and Applications. Bullhorn User provisioning happens in parallel with schema setup; we validate that every Nextal User has a corresponding Bullhorn User before record migration begins. Any Nextal User without a Bullhorn User is placed in a reconciliation queue for the customer's Bullhorn admin to provision.

Nextal custom fields on Jobs require field-level mapping to Bullhorn JobOrder custom fields. We extract the field schema (label, data type, required flag, picklist values), create the corresponding Bullhorn custom fields before migration, and map values during the JobOrder import. Picklist-type custom fields are created as Bullhorn picklist fields with the same value set; text, number, and date fields use their Bullhorn equivalents.

Nextal custom fields on Candidates map to Bullhorn Candidate custom fields using the same field-type equivalence logic. We create Bullhorn custom fields in the destination org sandbox before production migration, extract the field schema during discovery, and map values during the Candidate import. Any Nextal custom field without a Bullhorn equivalent is flagged in the discovery report for the customer to decide whether to create it or drop it.

Resume and document attachments on Nextal Candidate records migrate to Bullhorn CandidateDocument records linked to the Candidate. We preserve file format (PDF, DOCX, RTF) and filename. Bullhorn's REST API accepts CandidateDocument creation via multipart upload; we batch attachments in groups of 20 and retry on transient errors with exponential backoff. Attachments larger than 25 MB are flagged for the customer's admin to upload manually post-migration.

Nextal stores multilingual email templates tied to job stages. We extract templates as HTML blobs with language-variant metadata during discovery. Bullhorn Email Templates use a different schema and editor; we do not import templates as code. Instead, we deliver a written inventory of each extracted template with its trigger, body content, and language variants so the customer's Bullhorn admin can recreate them in Bullhorn's template builder. This is documented in the automation handoff, not migrated directly.

If Nextal exposes any company or client organization data (distinct from Candidate employer records), we map it to Bullhorn Corporation. Bullhorn's CRM layer uses Corporation as the parent of Contacts, mirroring how Salesforce uses Account for Contact. We extract company name, website, industry, and address fields. If no company data exists in Nextal, we skip this object; Bullhorn Corporation records can be created manually or via Bullhorn CRM imports post-migration.

Some Nextal configurations expose an inbound Lead object separate from Candidate. We map these to Bullhorn Lead records if present. Bullhorn Lead is separate from Candidate and supports a different workflow (unsourced vs sourced candidates). We flag the existence of this object during discovery and map it with the same email-dedupe strategy used for Candidate migration.

Nextal's built-in job board distribution to LinkedIn and Indeed is a configuration setting, not a record. We extract the distribution flags per Job and document which boards were active at migration time. Bullhorn's job board distribution is configured inside Bullhorn; we provide a written record of the original distribution settings so the customer's Bullhorn admin can re-enable them in Bullhorn's job board integration module.