Bullhorn data migration: steps, timeline and contract checks

What does a Bullhorn data migration involve?#

A Bullhorn data migration moves a staffing firm's candidates, client contacts, companies, job orders, submissions, placements and activity history out of Bullhorn and into a new ATS or a standalone archive, with the links between them intact. The links are the hard part. A single placement ties a candidate to a job order, a client contact, pay and bill rates, and a trail of notes, calls and interviews.

Most firms do not import everything. Open jobs, active candidates and recent placements usually go into the new system, while older history goes into an archive the firm controls. Deciding that split early keeps mapping work focused and stops the project from stalling on records nobody will search day to day.

Which Bullhorn contract terms should you check first?#

The Bullhorn contract terms that matter most are the renewal and notice dates, the data return or export language, and whether any access continues after the term ends. Read the master subscription agreement together with every order form, because order forms often carry the dates, user counts and add-on products that the main agreement does not.

Set the cutover date only after this review. A migration planned around the wrong renewal date forces either a rushed extract or an unplanned renewal, and neither is a good position from which to ask for export help. Have counsel read the data and termination sections alongside the operations lead.

• 1Term end date, auto-renewal language and the notice window for non-renewal.
• 2Data return or export language: the formats offered, whether attachments and files are covered, and any fee for assisted extraction.
• 3Any read-only or archive access after termination, and what it costs.
• 4Deletion of your data after the term, and whether the vendor will confirm it in writing.
• 5Separate contracts for third-party tools connected to Bullhorn, such as texting, onboarding, e-signature, back-office pay and bill, or VMS connectors, which may hold their own copies of candidate and placement data.
• 6Client and MSP agreements that restrict where candidate or program data may be stored or moved.

Export routes: list-view CSV, API extract or vendor-assisted extract#

The full Bullhorn record comes out through the API or a vendor-assisted extract, because a list-view CSV is a flat table of the columns on screen. A list export is useful for counts and spot checks, but it cannot carry attachments and usually leaves out full note history and the many-to-many links between candidates, jobs and submissions.

An API extract needs a developer or migration partner who can handle paging, limits and incremental pulls. Check Bullhorn's current API documentation and your contract for what your edition and access allow before scoping the work. Pull records in dependency order, so every link has something to point to, and keep the Bullhorn record ID on every row and every file.

• 1Reference data first: users, departments, status values, note types, picklists and custom field definitions.
• 2Companies and client contacts, with ownership and history.
• 3Candidates, including work history, education, skills and source.
• 4Job orders, then submissions and interviews linked to both candidates and jobs.
• 5Placements, with start and end dates, rates and every later change.
• 6Notes, tasks, appointments and email activity, each carrying the IDs of every record it touches.
• 7Attachments last, each indexed by the Bullhorn ID of the record it belongs to.

Mapping Bullhorn records to a new ATS#

Mapping Bullhorn records to a new ATS decides whether the new system reflects how your desks actually work, so it deserves more attention than any other stage. Start with status values and note types: every submission and placement status needs a clear match, or pipeline history collapses into a few vague stages, and note types are what let anyone later tell a prescreen from a reference check.

Custom fields carry much of a firm's process knowledge, such as shift preferences, clearance levels, specialty codes or client-specific requirements. The label recruiters see in Bullhorn can differ from the field name in an API export, and labels often stopped matching real use long ago, so have each desk define its fields before anyone maps them.

How long does a Bullhorn migration take?#

A Bullhorn migration takes as long as its slowest dependency, which is usually the contract notice window, the custom field mapping or the attachment extract rather than the raw number of records. Two firms of similar size can face very different timelines because one kept Bullhorn close to standard and the other layered years of custom fields and workflows on top of it.

Plan backwards from the contract end date rather than forwards from kickoff, and never schedule cutover for the last day of access. The order of work below holds for most firms; the dates between steps depend on the factors in the table.

• 1Non-renewal notice sent, and acknowledged by the vendor, before the deadline in your order form.
• 2First trial extract of every record type and attachment, used to build and test the field map.
• 3Test import of one pilot desk, followed by fixes to mapping and duplicate rules.
• 4Second trial extract and full test import, to prove the fixes.
• 5Data freeze, final delta extract and cutover, with access to spare.
• 6Validation sign-off and an archive check while Bullhorn can still be opened.

Validating the import before Bullhorn access ends#

Validation confirms that the new ATS holds the same records, links and history as Bullhorn, and it has to finish while you can still open Bullhorn to compare. General counts and sign-off matter, but the checks below target the places where Bullhorn histories most often break.

• 1Counts per record type in the extract match Bullhorn's own totals for the same filters, including any archived or deleted records you chose to keep.
• 2A note logged against both a candidate and a job order appears on both records in the new ATS.
• 3Placements with rate or date changes show the full sequence, not only the latest values.
• 4Submission status histories keep their dates, so time-to-submit and time-to-fill can still be calculated.
• 5Records owned by departed recruiters still show their original owner.
• 6Resumes and signed documents open and sit on the right candidate or placement.
• 7Each desk head confirms their own records in writing before the account is closed.

Illustrative: a staffing firm moves off Bullhorn without losing its history#

Illustrative: a fictional regional staffing firm runs light industrial and IT desks on Bullhorn and decides to move to a new ATS. The operations lead reads the order forms first and finds that the non-renewal notice window closes earlier than the team assumed, so cutover moves to a date that leaves room for a second extract.

During mapping, the IT desk explains that a custom field labeled for shift preference has held security clearance levels for years, so it maps to a clearance field instead. The firm imports open job orders, active candidates and recent placements. Older submissions, interview feedback and closed placements go into a read-only archive indexed by record ID, and when a client audit later asks about an old placement, the archive answers it without reopening a Bullhorn account.

How SourceX looks at an archived Bullhorn history#

SourceX looks at an archived Bullhorn history as a record of recruiting coordination: job orders, submissions, client feedback, interviews and placement outcomes, linked in sequence. Candidate personal data is the sensitive part, so preparation removes names, contact details and other identifying details, and resumes are often excluded entirely.

A review runs through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and it starts from a description of the archive alone: which system, which record types and how many years. The firm approves every step, and a SourceX Evidence Packet for each package covers provenance, licensing rights, permitted use, the privacy record and release authorization.