The 12-Step Bullhorn Migration Checklist for 2026

A Bullhorn migration is not a data export and a weekend of imports — it's a multi-week project that touches candidate records, job orders, placements, commission structures, and every integration a desk has bolted on over the years. Get the sequence wrong and a recruiter loses a week of pipeline history; get the data mapping wrong and a placement's commission math is off by the time payroll runs.

Most firms underestimate this project because Bullhorn itself is easy to use day to day, which creates a false sense that leaving it will be equally simple. It isn't the software that makes migrations hard — it's the years of accumulated custom fields, one-off integrations, and tribal knowledge about "how we actually do commission splits here" that never made it into any documentation. A checklist forces that tribal knowledge into a written plan before it becomes a mid-project surprise.

TL;DR: Most failed Bullhorn migrations don't fail because the destination ATS is worse — they fail because nobody mapped the hours before they started. Treat the cutover as a 12-step project with an owner per step, a validation pass before cutover, and a fallback window, and the migration becomes a scheduling problem instead of a crisis.

Where the Hours Actually Go When a Desk Leaves Bullhorn

Before picking a weekend to "just do it," it helps to see where a migration actually burns time. Firms that skip this step consistently underestimate the data-validation phase, which is where most of the real risk lives — and most vendor sales decks quietly leave it out of the timeline entirely.

Add it up and a 30-desk firm is realistically looking at 75-130 combined hours spread across ops, finance, and IT — not the "one weekend" most vendors imply. Scale to 75 desks and the same project stretches toward 145-215 hours, because record volume and integration count both grow faster than headcount does.

What "Migrating Off Bullhorn" Actually Means

At its core, an ATS migration is the controlled transfer of candidate, client, job order, and placement records from one system of record to another without losing referential integrity between them — a placement still has to point at the right candidate and the right job order after the move, or commission and reporting break.

A Short Glossary for Migration Planning

• Field mapping — the document tying each Bullhorn field to its destination equivalent, including custom fields a desk actually relies on.

• Parallel run — running both the old and new system side by side for a defined window so mismatches surface before go-live, not after.

• Referential integrity — the requirement that linked records (a placement, its candidate, its job order) still point at each other correctly post-migration.

• Data classification — sorting records into "core" (must migrate live) versus "historical" (can move as read-only archive).

• Cutover window — the scheduled period when the desk switches from the old system to the new one as the system of record.

• Decommission delay — the deliberate period after go-live where the old system stays accessible read-only in case something needs to be re-pulled.

Who this is for: staffing and recruiting firms of 10-150 users currently on Bullhorn who are evaluating or have already signed with a new ATS/CRM and need a structured cutover plan rather than an ad hoc export.

Red flags: Skip this checklist if you're a solo recruiter with under 500 total candidate records, have no commission or placement history to preserve, or haven't yet signed with a destination platform — get the contract finalized first, since field-mapping work is wasted if the destination changes.

The 12-Step Bullhorn Migration Checklist

1. Freeze the scope. Decide, in writing, which record types migrate (candidates, job orders, placements, notes, tearsheets) and which get archived instead. Scope creep mid-migration is the single biggest cause of blown timelines.

2. Run a full data audit. Export a record count by entity type and flag duplicates, stale records, and orphaned notes before you map a single field. This is also the point where it's worth comparing your plan against the base 12-step checklist for a Bullhorn migration to confirm nothing scope-critical got missed.

3. Build the field map. Match every Bullhorn field your desk actually uses — not every field that exists — to its destination equivalent, including custom fields recruiters rely on daily.

4. Classify data as core vs. historical. Core data (active candidates, open job orders, current placements) needs full fidelity; historical data can often move as read-only archives instead of live records.

5. Validate placement and commission logic separately. This is where JobSubmission.status transitions (Submitted → Interviewing → Placed) tie to commission calculations — get finance to sign off on the mapped logic before cutover, not after the first paycheck.

6. Inventory every integration. Job board postings, VMS connections, payroll exports, and email sync all read from or write to Bullhorn today; each needs a re-pointing plan.

7. Set a parallel-run window. Run both systems side by side for 1-2 weeks so recruiters can spot-check that a submittal in the new system matches what Bullhorn would have shown.

8. Migrate in waves, not all at once. Move historical/archived data first (lower risk), then active pipeline data closer to cutover, so most of the volume is already validated before the pressure window.

9. Train on the new system before go-live, not during it — a recruiter learning a new UI while also chasing live submittals is how candidates fall through.

10. Set a hard cutover date with a fallback window. Give the team 48-72 hours where Bullhorn stays read-only accessible in case something needs to be re-pulled.

11. Reconcile record counts post-migration. Compare entity counts and spot-check a sample of placements against source data before declaring the migration complete.

12. Decommission on a delay, not immediately. Keep Bullhorn in read-only mode for 60-90 days minimum — audits, disputes, and "where did this note go" questions surface weeks after go-live, not on day one.

Consider a 45-recruiter staffing firm migrating 18,400 candidate records, 2,300 open job orders, and 640 active placements off Bullhorn over a 6-week window. During the parallel-run phase, roughly 60 JobSubmission.status transitions a day need to match between old and new systems before the desk trusts the cutover — a mismatch rate above a handful per day is the signal to pause and re-check the mapping rather than push through to go-live.

US Tech Automations can run that reconciliation step automatically — watching for JobSubmission.status changes in the new ATS and flagging any placement whose commission math doesn't match the mapped Bullhorn logic, before a recruiter notices the discrepancy on payday. See how a recruitment workflow like this gets configured for a live desk.

In the export-and-audit phase, US Tech Automations can also pull the full candidate and job order inventory from Bullhorn on a schedule, tag duplicates and orphaned notes automatically, and hand ops a cleaned worklist instead of a raw CSV dump — cutting the 20-35 hour audit phase down to a review-and-approve task instead of a manual scrub. That kind of scheduled, tagged export is also why recruiting teams reach for a 12-step checklist for migrating in the first place — the risk was never the destination platform, it was always the untracked hours in between.

Quick-Reference: Step, Effort, and Blocking Gates

Eight of the twelve steps above are hard blocking gates — meaning the project shouldn't advance past them without sign-off, not just a checked box.

Bullhorn Migration: Manual vs. DIY vs. Orchestrated

A DIY Zapier or Make bridge can move new records forward reasonably well once it's built, but it wasn't designed for a one-time bulk historical migration with referential integrity requirements — a broken zap mid-migration means a candidate record with no linked job order, and per-task pricing gets expensive fast across tens of thousands of records. US Tech Automations instead orchestrates the whole sequence — export, mapping, validation, and reconciliation — with an audit trail and a human approval step before anything is marked final, which is the piece a point-to-point automation tool doesn't provide.

When NOT to use US Tech Automations for this: if your desk runs under 1,000 total candidate records and has no commission-tied placement history, Bullhorn's own native export tools plus a weekend of manual QA are genuinely cheaper than standing up an orchestrated migration for a dataset that small.

Building Your ATS Migration Data Plan

An ATS migration data plan is the document that tells every stakeholder which fields move, in what order, and who signs off — without it, "the migration" becomes whatever the last person who touched the export decided to include. A written plan also gives finance and ops a shared reference to point back to when a placement dispute comes up three weeks after go-live, instead of everyone relying on memory of what was agreed in a kickoff call.

According to SHRM Talent Acquisition Benchmarking research, white-collar roles routinely take several weeks to fill — which is exactly why a migration that drops even a portion of active pipeline history is expensive: a lost candidate note or missed follow-up date can mean restarting weeks of sourcing work on a role that was already in motion. According to LinkedIn Talent Insights, most InMail outreach to passive candidates goes unanswered on the first attempt, which means the sourcing history sitting in Bullhorn's notes and activity log — every prior touch on a passive candidate — is worth more than it looks on an export spreadsheet.

Common Bullhorn Migration Mistakes

According to BLS employment services data, staffing and recruiting firms make up a measurable share of U.S. business services employment — which is why even a 30-desk firm's typical 75-130 hour migration project ripples into every client relationship that desk manages if it goes wrong. Separately, according to Gartner, steps 2, 5, 7, and 11 of this checklist are marked as blocking gates precisely because enterprise software migrations that skip a validation phase are far more likely to run over schedule than ones that build validation in from the start.

None of these mistakes are unique to Bullhorn migrations specifically — they show up in any system-of-record cutover where historical data has downstream financial consequences. What's specific to staffing is the commission layer: a CRM migration for a sales team might tolerate a few dropped notes, but a recruiting desk's commission math touching the wrong placement record turns into a payroll dispute within one pay cycle.

That's also why the parallel-run window earns its place on the checklist even when a project is under time pressure to cut it short. A recruiter who spots a mismatched submittal during a scheduled two-week parallel run is a minor fix; the same mismatch discovered by a candidate disputing a fee three months post-migration is a much more expensive conversation, and by then the audit trail that would explain what happened is often gone.

FAQs

What should a Bullhorn migration checklist actually cover?

It should cover data audit and field mapping, entity-by-entity export order, commission and placement validation, integration re-pointing, a parallel-run test window, and a delayed decommission — not just "export candidates and import them."

How long does leaving Bullhorn for a new ATS typically take?

For a 20-50 recruiter desk, a full migration including parallel-run validation typically runs 6-10 weeks; smaller desks with under 1,000 records can often finish in 2-3 weeks.

What is an ATS migration data plan?

It's the document mapping every data category (candidates, job orders, placements, notes) to a destination field, an owner, and whether it migrates live or moves to a read-only archive — it's what keeps a migration from becoming ad hoc mid-project.

Do commission and placement records need special handling when leaving Bullhorn?

Yes — placement and commission logic ties directly to job submission status history, and mapping it incorrectly is one of the most common sources of post-migration payroll disputes.

Can a small staffing desk migrate off Bullhorn without automation?

Yes, if the desk has under roughly 1,000 total candidate records and simple commission structures; larger or more complex desks benefit from automated reconciliation to catch mismatches a manual spot-check would miss.

Should Bullhorn be shut off immediately after go-live?

No — keep it in read-only mode for 60-90 days at minimum, since disputes, missing notes, and reporting questions routinely surface weeks after the official cutover date.

Key Takeaways

• US staffing industry revenue: $186B according to Staffing Industry Analysts 2025 forecast, which is exactly why a migration that damages placement or commission data carries real financial risk, not just an operational inconvenience.

• A 30-desk firm should budget 75-130 combined hours across ops, finance, and IT for a full migration — not a single weekend.

• According to the American Staffing Association, more than 3 million people work through American staffing companies in a given week — at that scale, even small per-placement data errors compound quickly across a desk's pipeline.

• Sequence matters: audit, map, classify, validate commission logic, then migrate in waves — not all at once, and not without an automated version of this checklist doing the reconciliation work in the background.

• US Tech Automations can automate the audit, reconciliation, and JobSubmission.status matching steps so a desk's leadership is reviewing a worklist instead of manually cross-checking spreadsheets.

Ready to see the migration reconciliation running on your own data? Get a walkthrough of a Bullhorn cutover built for your desk.