Bullhorn Migration: Moving a Desk Without Losing Data

Leaving Bullhorn is not really a software problem. It is an operations problem wearing a software costume. Your candidate history, your client relationships, and your live placements all sit inside one system, and every one of them has to arrive on the other side intact while the desk keeps billing.

That is the part the migration guides skip. Most of them are written by the tool you are moving to, so they promise a smooth switch and move fast on the messy middle. This guide does the opposite. It stays neutral, sticks to what Bullhorn’s own documentation says, and treats your working pipeline as the thing you protect above all.

If you have not yet picked a destination, start with the alternatives to Bullhorn for a recruiting agency. This page assumes the decision is made, and answers the harder question: how do you actually get out.

What moving a desk off Bullhorn actually involves

A migration has three jobs, and they run in this order. First, get your data out of Bullhorn cleanly. Second, load it into the new system so it is usable, not just present. Third, switch your team over without dropping a live mandate.

Each job has its own failure mode. Exports fail when nobody checks the record limits first. Imports fail when fields are not mapped and data lands in the wrong place. Cutovers fail when there is no owner and no test to say the move is done.

The good news is that all three are controllable. A mapped CSV move may be manageable with onboarding support. SQL backup conversion may need a database specialist. You need one accountable owner and checks for both record counts and changed values. The rest of this guide walks each job in turn.

For the vendor-neutral mechanics that apply to any ATS switch, field mapping, pilot samples, rollback rules, and a cutover matrix, use our ATS migration checklist for agencies as the control pack. This page adds the Bullhorn-specific layer on top.

What your Bullhorn instance is really holding

Before you export anything, list what you are actually moving. A Bullhorn agency instance usually holds far more than a candidate list. Underestimating this is where timelines slip.

Sort this list into two buckets: what you must carry, and what you can leave behind. You almost never need every record. Migrate only what you have a documented reason and a lawful basis to keep, inside your retention schedule. A smaller, cleaner dataset imports faster and validates faster.

Choosing a Bullhorn export route: CSV, API, or backup

Bullhorn documents several export routes. Choose one against your inventory and test what the destination can load. The documentation below was checked on September 8, 2026.

Exporting data from Bullhorn describes list-view CSV and REST API export. CSV access is Admin-only by default, subject to company settings. Entitlements set limits of 5,000 to 20,000 records per pull; extra columns can reduce capacity. API export supports larger volumes with API access, documented for Front Office Growth and Enterprise editions. Confirm access and coverage with Bullhorn before planning that route.

The supported export fields include candidate, contact, company, job, placement, submission, task, and web response fields. Check the actual fields you need; this does not establish a Notes list-view CSV export. For notes, verify API coverage or use the documented backup route.

Bullhorn’s backup documentation describes Microsoft SQL Server data, including records and notes. A standard backup includes attachments added from the first day of the previous month through the request date. A final/full backup includes all attachments in their native formats. Only Account or Support Contacts can request backups, with two contact signatures required. Downloads come as compressed files through secure FTP. Arrange SQL restoration and conversion with a specialist; Bullhorn Support does not map restored data. Confirm timing early: Bullhorn allows one backup per 30 days, and a requested cutoff date requires a later backup run.

Export Management is a separate personal-data request workflow. It requires GDPR or CCPA Support and Admin-level access. Its email and SMS exports are inbound-only text files. Its separate resume-download example concerns an individual request, not a requirement to download every migration attachment manually. Confirm message coverage for your chosen migration route rather than applying this workflow’s limits to all exports.

Choose the export route before setting the cutover date. Prove that the destination can load each required data type, or agree on a usable archive for anything it cannot hold.

How to sequence a parallel run while the desk keeps billing

The safest way to switch is to never go dark. You keep Bullhorn live and authoritative while you build up and check the new system beside it. This is a parallel run, and it is the single most important habit for protecting revenue.

Start by loading a pilot. Export a representative slice, one recruiter’s desk or one client, and import it into the new tool. Check that fields landed correctly, notes attached to the right record, and resumes open. Fix your field map before you touch the full dataset. A pilot catches mapping errors while they are cheap.

Once the pilot passes, load the full historical dataset while Bullhorn stays the system of record. New activity still happens in Bullhorn during this phase, so nobody loses a beat. You are validating the new tool, not yet living in it. Keep all live entries and edits in Bullhorn, with no dual entry. Record the historical snapshot time and preserve stable Bullhorn IDs, plus a mapping to destination IDs. Agree how to capture later changes before taking that snapshot.

A cutover order that keeps consultants placing

Cutover is the short, sharp moment when the new system becomes authoritative. Do it in a quiet window, a Friday evening or a slow week, not mid-sprint on a hot mandate.

Freeze all Bullhorn writes: new entries, edits, deletions, integrations, scheduled jobs, and automated writes. Record the freeze time. Reconcile everything created, modified, or deliberately deleted since the historical snapshot, including owner and mandate-stage changes. Confirm your export route can capture these changes; if it cannot, compare a fresh complete extract with the snapshot by stable ID. Keep an explicit deletion log so missing export rows are not mistaken for approved deletions.

Use the Bullhorn-to-destination ID map to update existing records in place. Insert only IDs not already mapped, and apply logged deletions according to the agreed retention plan. Test that rerunning the delta does not create duplicates. Reconcile IDs, changed values, relationships, and counts before sign-off.

Only after the acceptance checks pass does the new system become authoritative. Move the team and integrations together, and keep Bullhorn read-only for the agreed archive period. If checks fail, postpone the switch and follow the rollback plan in the control pack.

The reason for read-only matters. Your consultants keep placing on live mandates in the new system from Monday, but if anyone needs to check an old thread, the archive is still there. You remove that safety net only after the acceptance tests below have passed and a defined archive period has elapsed.

The acceptance tests that prove your Bullhorn migration worked

A migration is not done when the import finishes. It is done when you can prove nothing important was lost. Skip this step and you find the gaps months later, usually when a client asks for a candidate you can no longer find.

Write these tests down as a sign-off sheet with a name against each line. The person who owns the migration signs it, and that signature is what lets you close Bullhorn with confidence rather than hope.

What a Bullhorn migration really costs you in time

Nobody can hand you an exact hour count, because it depends on your data volume and how many custom fields you carry. What you can plan for is the shape of the effort.

For a desk of three to thirty recruiters, budget two to four weeks of elapsed calendar time, most of it part-time. The heavy hours sit in preparation and validation, not in the imports themselves. Deciding what to keep, mapping fields, running the pilot, and reconciling counts take real attention. The cutover weekend itself is short.

The mistake that inflates the bill is skipping the pilot. Teams that load everything at once, then discover a mapping error across ten thousand records, spend the time twice. A small pilot up front is the cheapest insurance in the whole project.

Where Leonar fits once you have left Bullhorn

Everything above is destination-neutral on purpose. It is your plan no matter where you land. Here is the honest version.

Leonar supports mapped CSV imports for contacts and companies, including suitable exports from a previous ATS, with dedicated onboarding support. Before committing to a Bullhorn migration, confirm handling for other entities, relationships, attachments, and message history with the onboarding team. Agree what will be imported, what needs conversion, and what must stay in an archive. Validate that scope with a sample import.

On cost, Leonar publishes its prices rather than routing every buyer to a quote. Starter is $119 per user per month and Professional is $199 per user per month, with Enterprise scoped to the team. You can see current plan limits and included credits on the published pricing page. If you are weighing the two systems side by side, the Leonar versus Bullhorn comparison lays out the differences, and the Bullhorn pricing breakdown applies a year-one budgeting method to the suite you are leaving.

Bring a sample export and your acceptance sheet to the onboarding discussion. A tested field map and an agreed scope give your desk a concrete basis for choosing a cutover date.

Bullhorn migration questions agency owners ask

What data can you export from Bullhorn yourself?

List-view CSV exports cover supported fields, including candidate, contact, company, job, placement, submission, task, and web response fields. Admin access is required by default; entitlements and columns affect limits. API export requires API access. Account or Support Contacts can request a SQL backup. Check the route and field coverage before choosing.

Does everything transfer in one export when you leave Bullhorn?

Export and import are separate checks. CSV is one route; API and backups are others. Standard backups have limited attachment coverage; final/full backups include all files. Export Management is a personal-data workflow with inbound-only email and SMS text exports, not the definition of every migration route. Confirm destination support for each data type.

How long does a Bullhorn migration take for a small agency?

For a desk of three to thirty recruiters, plan two to four weeks of elapsed time, not full-time work. Most of it is preparation and checking: agreeing what to keep, mapping fields, running a test import, and validating counts. The actual cutover weekend is short. Larger databases and more custom fields extend the timeline, mostly in mapping and validation.

Can you keep placing candidates during a Bullhorn migration?

Keep Bullhorn as the only system of record during the parallel run. At cutover, freeze all writes, including edits and automated writes. Reconcile records created, modified, or deliberately deleted since the snapshot using stable IDs. Switch all work to the new system only after acceptance checks pass; retain Bullhorn read-only for the agreed archive period.

How do you know a Bullhorn migration actually worked?

Reconcile counts and stable IDs, including creations, modifications, and deliberate deletions since the snapshot. Verify an existing record whose owner or stage changed during the parallel run: its destination ID must stay the same and its values must match Bullhorn. Check fields, relationships, notes, files, and agreed message coverage before switching. Matching counts alone cannot prove success.

Frequently asked questions

What data can you export from Bullhorn yourself?

List-view CSV exports cover supported fields, including candidate, contact, company, job, placement, submission, task, and web response fields. Admin access is required by default; entitlements and columns affect limits. API export requires API access. Account or Support Contacts can request a SQL backup. Check the route and field coverage before choosing.

Does everything transfer in one export when you leave Bullhorn?

Export and import are separate checks. CSV is one route; API and backups are others. Standard backups have limited attachment coverage; final/full backups include all files. Export Management is a personal-data workflow with inbound-only email and SMS text exports, not the definition of every migration route. Confirm destination support for each data type.

How long does a Bullhorn migration take for a small agency?

For a desk of three to thirty recruiters, plan two to four weeks of elapsed time, not full-time work. Most of it is preparation and checking: agreeing what to keep, mapping fields, running a test import, and validating counts. The actual cutover weekend is short. Larger databases and more custom fields extend the timeline, mostly in mapping and validation.

Can you keep placing candidates during a Bullhorn migration?

Keep Bullhorn as the only system of record during the parallel run. At cutover, freeze all writes, including edits and automated writes. Reconcile records created, modified, or deliberately deleted since the snapshot using stable IDs. Switch all work to the new system only after acceptance checks pass; retain Bullhorn read-only for the agreed archive period.

How do you know a Bullhorn migration actually worked?

Reconcile counts and stable IDs, including creations, modifications, and deliberate deletions since the snapshot. Verify an existing record whose owner or stage changed during the parallel run: its destination ID must stay the same and its values must match Bullhorn. Check fields, relationships, notes, files, and agreed message coverage before switching. Matching counts alone cannot prove success.