The Definitive Guide to Migrating to Bullhorn

Bullhorn, Inc. is an American cloud company headquartered in Boston, with operations in St. Louis, London, Brighton, Sydney and Rotterdam ¹. The platform provides applicant tracking, CRM and operations software for the staffing industry, and more than 10,000 firms run their recruitment workflows on it ¹².

The typical Bullhorn customer is a staffing or recruitment agency — five to several hundred recruiters — managing candidates, client contacts, job orders and placements in one connected workflow. Compared with generalist ATS products like Greenhouse, Bullhorn positions on staffing-industry depth: Sendouts, Tearsheets, VMS Sync and a marketplace of 300+ pre-integrated partners ¹². Compared with JobAdder or Crelate, it positions on platform maturity and a richer toolset for staffing workflows.

The shapes of migration that actually land on Bullhorn tend to fall into four patterns. First, homegrown-ATS replacements: an agency moving off a spreadsheet, an Access database or a bespoke in-house tool with limited outreach capabilities ¹¹. Second, vertical-ATS swaps, where the source is Crelate, JobAdder, PCRecruiter or Avionté and object parity is reasonable but custom-Category structures are not.

Third, generalist-ATS exits — Greenhouse, Workable, Lever — where the source pipeline-per-job model has to be re-shaped into Bullhorn's Candidate → JobSubmission → Placement chain. Fourth, M&A consolidation, where an acquired agency runs on a different ATS. A Crelate migration usually has clean entity parity but messy custom-Category labels; a Greenhouse migration has rich scorecards that do not move natively.

What makes migrating *to* Bullhorn easier than the category average is the Bullhorn Data Loader — an open-source Java tool maintained by Bullhorn that ingests CSV for nearly every entity and upserts by externalID ³.

What makes it harder than the average is the entity ordering constraint — Candidates must exist before JobSubmissions, JobOrders before JobSubmissions, ClientContacts before Notes — and the Custom Import quirk where clicking *Next* more than once on the preview screen silently duplicates records ¹⁴². Resume Parser settings, EEOC fields and JobSubmission status histories all need explicit decisions up front.

Reports built in Bullhorn Reporting (formerly Canvas), Pulse activity rules and Bullhorn Automation journeys do not import — they are rebuilt from documentation. Teams that scope for that work finish on time; teams that assume parity do not.

Teams that scope for the rebuild work up front finish on time; teams that assume parity do not.

Bullhorn's ATS is built around a small set of staffing-specific entities, each with default and custom fields, and associations that connect them.

Before you can map a field on the source side, you need to know which destination entity the row belongs on, which fields it requires, and which value will serve as its upsert key. The table below summarises the entities you will touch.

Bullhorn's upsert key is externalID — a single-line text field on every core entity that you set yourself and use to match incoming rows against existing records ³. Several entities also expose customTextX fields that can be promoted to external-ID-style match keys via the Data Loader ExistField setting ³.

Plan for externalID on day one: stamp the source primary key (or a UUID) into every row before export, and use it on every re-run so updates are deterministic. Without externalID, the Custom Import wizard matches on a name/email heuristic unsafe for production ¹⁴².

Custom field edit types determine validation and storage; the catalogue below covers what you can model and the limits that apply ¹⁷.

Relationships in Bullhorn are modelled as to-one and to-many associations between entities — JobSubmission.candidate is to-one, Candidate.notes is to-many. The Data Loader resolves them by externalID in cross-reference columns.

There is no native cascade-delete: deleting a parent does not delete child Notes, JobSubmissions or Appointments, a behaviour to reproduce via Bullhorn Automation or scripted cleanup if your source relied on it.

The single best predictor of a clean Bullhorn migration is how much work you do on the source side before the first Data Loader command runs. Bullhorn's own guidance on data hygiene notes that stale candidate records, duplicate emails and outdated Categories are the main reason post-migration search results drift from what recruiters expect ²⁹.

The single best predictor of a clean migration is how much work you do before the first Data Loader command runs.

Treat the source export as raw material that needs shaping to Bullhorn's expected formats — email lowercased, phone normalised, picklist values rewritten to destination drop-down values, dates as MM/DD/YYYY or ISO-8601, and owners resolved to Bullhorn usernames.

Source-side prep

• Audit and dedup the source candidate database before export — email-case-only duplicates, role-based addresses and obviously stale records (last-touched 5+ years ago, never placed) should be pruned now, not after they hit Bullhorn.
• Stamp externalID on every source record — Candidate, ClientContact, ClientCorporation, JobOrder, JobSubmission and Placement. Use the source primary key or a UUID. This is the single most-important prep task because every re-run, reconciliation query and Automation lookup depends on it ³.
• Normalise picklist values for Candidate status, JobOrder status, JobSubmission status, Placement employmentType and every custom drop-down — Bullhorn matches on the Field Mappings value, not the display label, and silently drops rows targeting undefined values ⁶².
• Decide resume-file scope. Each candidate has zero, one or many resumes. Decide latest-only, all-versions, or none — the resume leg is its own pipeline that runs *after* Candidate rows land.
• Convert dates to Eastern Time. Bullhorn stores all datetimes in ET on the server regardless of user timezone — a date loaded with no offset is interpreted as ET midnight, silently shifting dates by up to 24 hours for non-US-east sources ²⁷⁷¹.

Destination-side prep

• Provision a sandbox — Bullhorn supports Developer, Partial and Full-Copy Sandboxes refreshed daily, weekly and monthly, with Partial capped at 5 GB and 10,000 records per object ⁹²¹⁵⁶. Use Partial or Full-Copy for the dry-run.
• Provision Corporate Users first, ideally via SSO, and assign User Types and Departments before importing — owner assignment falls back to the load user if a referenced owner does not exist ¹³¹³³.
• Pre-create every custom field in Admin → Field Mappings on the right entity with the right edit type — Custom Float, Integer, Text and Date have asymmetric retype rules that catch teams later ¹⁷.
• Pre-create every Custom Object via a Bullhorn Support ticket — Custom Objects cannot be created through the UI directly ¹⁶¹⁶⁰, and they must exist before child rows can be loaded.
• Set Resume Parser settings. Enable email-based resume parsing via support ticket if backfilling through the parser, and decide which parsed fields overwrite vs. fill blanks ¹⁰⁶.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours for teams whose recruiters live in the system. Train recruiters on Candidate search, JobSubmission status transitions and the Notes tab before go-live. A typical small-agency migration runs two to six weeks of elapsed time ¹⁰⁴; data depth, custom Categories and resume volume drive the upper end.

Bullhorn exposes two main load paths and the right one depends on dataset size, entity mix, and whether you need to re-run idempotently. The Custom Import wizard covers small Candidate/Contact/Lead loads. The Bullhorn Data Loader handles repeatable, large CSV loads across all entities.

Custom Import wizard

The native Custom Import lives at Menu → Tools → Custom Import ¹⁴². It accepts CSV only — Excel files must be saved as CSV first — and supports just three entities: Candidate, Contact and Lead ³². The flow: pick Record Type, upload CSV, accept the auto-mapping, name the template, click *Perform Import*, review the first 100 records, click *Next* exactly once, and wait.

The single most-important warning in the Bullhorn docs: clicking *Next* more than once on the preview screen creates duplicate records ¹⁴². Teams that lose patience because the page appears unresponsive find every candidate doubled. Recovery: mass-delete the newly-added rows (they default to *Imported* status) and re-import the cleaned file ¹³³.

Bullhorn Data Loader

The Bullhorn Data Loader is an open-source Java tool published at github.com/bullhorn/dataloader and maintained by Bullhorn ³¹⁴. It runs from the command line against a directory of CSV files whose names start with the target entity — Candidate.csv, JobOrder.csv — and supports load, update, delete and convertAttachments commands.

Configuration lives in dataloader.properties, where the ExistField setting declares the upsert key per entity (typically externalID, but any unique field works) ³. With ExistField set, Data Loader does upsert; with it commented out or absent, every row is a fresh insert.

Data Loader handles cross-reference associations via column names like clientCorporation.externalID — set the source-side parent key in that column and Data Loader resolves it at load time. The same pattern works for Categories, Business Sector, Specialty and Custom Object parents.

Mapping is where every staffing-ATS migration earns its scars. The schema decisions in your mapping spreadsheet determine whether recruiters find candidates on day two, whether placement reports work on day five, and whether the team trusts the data by day thirty.

Work entity by entity in strict import order: ClientCorporations first (so JobOrders and ClientContacts can associate), then ClientContacts, Candidates, JobOrders, JobSubmissions, Sendouts, Placements, Notes / Tasks / Appointments, and resume files and Custom Objects last.

Candidates

ClientCorporations and ClientContacts

JobOrders, JobSubmissions and Placements — the ATS deep dive

The job-requisition pipeline runs JobOrder → JobSubmission → Sendout → Placement, with status transitions logged as history on each entity. A JobOrder is the open requisition (e.g. *Senior RN, Boston*), a JobSubmission is a candidate's application against it, a Sendout is when that submission is packaged and sent to the client, and a Placement is the confirmed hire.

Recreate every JobOrder status (Open, Covered, Lost, Closed) and every JobSubmission status (New Lead, Internal Submission, Client Submission, Interview Scheduled, Offer Extended, Placed, Rejected) in Admin → Field Mappings before loading. Rows targeting an undefined status are silently rejected ⁶².

JobSubmission status transition history is one of the most-asked-about pieces of an ATS migration and one of the least-supported on import. Bullhorn does not expose a status-history table — the audit trail is built by repeated updates that each generate a history row ¹³⁴. To preserve the timeline, capture each transition as (submission_id, status, timestamp, user) and replay updates in date order, accepting that the *modifying user* will be the migration user, not the original recruiter.

Alternatively, store the legacy stage history verbatim in a Custom Text Block field on JobSubmission so it stays searchable, and let live history accrue forward from cutover.

Candidate sources, EEOC and Categories

Candidate source tracking lives on the source field plus a categoryID link to a Source category list. EEOC data (ethnicity, gender, veteran, disability) lives on dedicated Candidate fields and is reportable through Bullhorn's Standard Source Effectiveness and Diversity reports ¹⁵⁷. Treat EEOC fields as sensitive: confirm the source export is permitted under your retention policy and that the destination's privacy posture matches ¹³⁰.

Categories in Bullhorn are the tagging system — industry, skills, certifications, geographic specialties. They attach to Candidate, ClientContact, JobOrder and Placement. Pre-create the parent Category lists in Admin → Categories, then resolve source tags to Bullhorn Category IDs via a lookup table during transform. Mismatched Category names silently drop on import.

Resumes and file attachments

Resume and attachment migration is its own pipeline that runs *after* the Candidate rows land. The Custom Import wizard does not handle files; the supported paths are Data Loader's convertAttachments and loadAttachments commands, which read a CSV of {candidate externalID, file path, file type} ⁷⁴, and the Bullhorn Automation Resume Upload survey for candidate self-service backfill ¹⁰⁶.

File-size cap for record attachments is 20 MB per file; supported types include doc, docx, odt, rtf, html, pdf, txt for resume parsing, plus PDF, MS Word, Excel and images for general attachments ⁷²⁷³. For large resume estates, most agencies keep originals in S3 or Azure Blob, load only the latest resume into Bullhorn, and store the archive deep link in a Custom URL field.

Notes, Tasks and Appointments — historical activity

Bullhorn supports importing Notes, Tasks and Appointments with their original dateAdded timestamps via Data Loader ⁵². Each Note carries an action (Call, Email, Meeting, General), commentingPerson (recruiter), commentsText (body), and one or more associations to Candidate, ClientContact, JobOrder or Placement parents.

Bullhorn Notes do not support rich-text formatting — pasting HTML, images or charts is rejected and only plain text survives ⁵². Convert source rich-text bodies to plain text or a Markdown-style structure during transform, otherwise the body arrives blank.

Custom-field mapping strategy

Resist the urge to map every source custom field one-to-one. Migrate only the custom fields used by an active recruiter workflow or report in the last 12 months. Excess fields weaken Field Mappings governance, slow Bullhorn Search indexing, and make Reporting harder to wire.

For picklist fields whose source values do not match the destination, either: (1) extend the destination drop-down in Admin → Field Mappings, (2) collapse adjacent values during transform, or (3) introduce a parallel Custom Text field holding the legacy value verbatim. Calculated / formula fields do not import — Bullhorn has no formula type, so source formulas must be replicated via Bullhorn Automation or pre-computed before export.

Audit trail, ownership and original timestamps

Bullhorn maintains an audit trail on the Activity tab of each record, with the modifying user recorded as the user that initiated the change ¹³⁴. System-managed dateAdded and dateLastModified can be overwritten on creation via Data Loader for most entities — unusual for the category and a quiet win for historical timelines.

However, dateAdded is interpreted in Eastern Time on the Bullhorn server ²⁷⁷¹. A source datetime of 2024-08-14 12:00 NZST round-trips as 2024-08-14 00:00 ET if you do not convert, shifting dates by up to 24 hours for non-US recruiters. Convert every datetime to ET explicitly during transform and document the convention in your migration spec.

Owner assignment during import works only if the username or CorporateUser ID exists at load time; rows whose owner cannot be resolved are imported with the load user as owner, silently breaking Pulse attribution and per-recruiter reporting ¹³³.

Validation is the bridge between Data Loader finishing and recruiters being allowed in. A three-stage validation works best: a 10 percent pilot load with recruiter spot-checks, the full load with real-time row-count monitoring, and a 30-day audit driven by Bullhorn Reporting. The most reliable signal is recruiters verifying their own desks — they know what right looks like better than any reconciliation script.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5 percent variance gets investigated before users get login access.

• Total Candidates loaded vs. source — minus deliberately excluded rows (stale, opt-out, duplicate emails).
• Total ClientCorporations and ClientContacts loaded vs. source — checking that name-based collapse did not over-merge separate clients.
• Total JobOrders per status vs. source, plus sum of salary per JobOrder.status — a non-trivial dollar variance signals a status-mapping error or currency-precision drop.
• Total JobSubmissions per JobOrder vs. source, and JobSubmission counts per status — confirms the candidate pipeline shape per requisition matches.
• Total Placements per employmentType (Contract, Contract-to-Hire, Perm) and sum of payRate per period — drives billing-side reporting from day one.
• Notes, Tasks and Appointments per entity with dateAdded round-tripped — date-bucket the comparison to confirm timestamps were not silently shifted by the ET conversion ²⁷.
• Owner distribution per entity — group by owner.username and confirm no record landed unowned that should not have ¹³³.
• ExternalID integrity — count distinct externalIDs per entity; any nulls or duplicates indicate the upsert key was not consistently set ³.

On top of reconciliation, run a manual spot-check: pick 30 random Candidates across statuses and verify each field against the source UI. Pick five high-value JobOrders and trace the full association graph — ClientContact, Candidate, JobSubmission, Sendout, Placement, Notes. If discrepancies show up in three or more of the 30, halt the load, fix the root cause, and re-run by externalID upsert.

Bullhorn does not ship a native bulk-undo. The recovery path: every imported row carries a Custom Text field stamped *Import Batch ID*, and if catastrophe strikes, a mass-delete in Admin → Mass Update filtered by that batch ID rolls the import back ¹²⁴¹²⁷. Bullhorn Support can also perform a *Hard Delete of Existing Data*, but the operation is one-way and irreversible ¹²⁷.

The real rollback strategy remains: export everything to S3 before the import starts, stamp every imported row with an Import Batch ID, and bulk-delete by that batch ID if recovery is needed.

Cutover sequencing: (1) source ATS goes read-only and the desk is notified; (2) a final delta export captures everything changed during the test window; (3) delta is loaded via Data Loader against externalID; (4) reconciliation runs; (5) recruiters get login access and a 48-hour hyper-care window; (6) source decommission is scheduled 30 to 90 days out, never same-day.

The Bullhorn Marketplace lists 300+ pre-integrated technology partners and a smaller cohort of certified implementation consultancies that handle migration work ¹¹². Bullhorn itself ships an in-house Implementation team that manages most small and mid-size agency migrations end-to-end, typically two to six weeks of elapsed work for mid-size firms ¹⁰⁴.

For agencies that want external help, the Bullhorn Marketplace lists a tier of long-standing Bullhorn-focused consultancies ¹¹². A separate band of specialist migration vendors focuses narrowly on Bullhorn import paths — published timelines run 1 to 3 days for a full migration on smaller datasets, and resume-extraction-as-a-service offerings handle parsing from email inboxes plus bulk loading.

On the ETL and iPaaS side, Fivetran, Airbyte, Workato and Integrate.io all support Bullhorn as source or destination. Their role is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that converts picklist values and resolves owner usernames, and the ongoing-sync layer post-migration.

Workato is common where the migration is bundled with workflow automation rebuilds; Fivetran and Airbyte are common picks for warehouse-first teams that want to reverse-ETL into Bullhorn.

Managed-migration cost ranges vary widely. A clean homegrown-database-to-Bullhorn load of under 25,000 Candidates with no resume backfill often lands in the $2,000–$10,000 range on top of the Bullhorn license. A Crelate-to-Bullhorn or Greenhouse-to-Bullhorn project with JobSubmission history, Custom Objects, resume migration and Automation rebuilds typically runs $15,000–$60,000, driven by record count, custom-field complexity and resume-file volume.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Bullhorn migrations and handles the field mapping, externalID upsert design, resume-file pipeline, JobSubmission history rebuild and validation work in Sections 5 and 7. Pricing is fixed-fee, based on record count and source platform, with separate line items for Custom Objects and resume-file depth so scope is transparent before signature.

This is one of several legitimate paths — the right choice depends on whether you want the in-house Bullhorn Implementation team, a Marketplace partner like Newbury, an iPaaS-first approach with Fivetran or Workato, or a specialist migration vendor. Explore FlitStack →