How to Migrate from Bullhorn Without Losing Your Data

Migrating off Bullhorn is one of those projects that agencies talk about for months before pulling the trigger. The fear is always the same: what if we lose data, break workflows, or grind placements to a halt during the switch? Those are legitimate concerns. But with the right plan, a Bullhorn migration is a two-to-four-week project, not a six-month ordeal.

This guide walks through the entire process — from the moment you decide to leave, through data export, field mapping, validation, parallel run, and go-live. Whether you are moving to Winnow Career Concierge or another platform, the steps are largely the same.

Why agencies leave Bullhorn

Bullhorn is the 800-pound gorilla of recruiting CRMs. It has been around since 1999, and for large enterprise staffing firms, it can be the right tool. But for small to mid-size agencies, three problems keep surfacing.

Cost creep. Bullhorn's base price is just the beginning. Marketplace add-ons for texting, sourcing, analytics, and automation each carry their own monthly fees. Agencies routinely report all-in costs of $150 to $300 per user per month once they stack the integrations they actually need.

Complexity tax. The platform was designed for enterprise workflows. That means deeply nested menus, heavyweight configuration, and a learning curve that punishes lean teams. New recruiters can take weeks to become productive.

Add-on fatigue. Need resume parsing? That is an add-on. Need AI matching? Another add-on. Need job distribution? Yet another vendor in the mix. Every layer adds cost, login friction, and potential points of failure.

None of this means Bullhorn is bad software. It means the cost-benefit math changes depending on your agency's size and complexity. If the math no longer works, migration is the logical next step.

Before you start: the pre-migration audit

Do not export a single record until you have answered these questions.

What data matters?

Not everything in your Bullhorn instance deserves to come along. Start by cataloging the data types you actually use day to day.

| Data type | Typical priority | Notes | |---|---|---| | Candidate records | Critical | Names, contact info, skills, notes | | Candidate resumes/attachments | Critical | PDFs, Word docs attached to records | | Job orders | High | Active and recently filled positions | | Placement records | High | Revenue history, start/end dates | | Company/client records | High | Billing contacts, terms, relationships | | Activity/note history | Medium | Emails, calls, meeting notes | | Custom fields | Medium | Agency-specific data points | | Tearsheets/hotlists | Low | Can usually be recreated quickly | | Old job orders (2+ years) | Low | Archive rather than migrate |

Be honest about what you need. Migrating everything "just in case" doubles the project timeline and introduces more opportunities for mapping errors.

Who owns the project?

Assign one person as the migration lead. This person does not need to be technical, but they need the authority to make decisions about data mapping without convening a committee every time a question comes up.

What is your target go-live date?

Work backward from a realistic date. Avoid going live during your busiest placement month. A slow week is your friend.

Step 1: Export your data from Bullhorn

Bullhorn provides several ways to get your data out.

Bullhorn Data Exporter (BDE). This is the native bulk export tool. It lets you export candidates, jobs, placements, companies, and contacts as CSV files. You will need admin access to use it.

Bullhorn REST API. If you have a developer on staff (or a migration partner), the REST API gives you more granular control. You can export custom fields, attachments, and activity history that BDE sometimes misses.

Manual CSV export. For smaller datasets, you can export directly from list views in the Bullhorn interface. This works fine for tearsheets and hotlists but is impractical for full candidate databases.

What to export

At minimum, export these entity types as separate CSV files:

1. Candidates — all fields including custom fields
2. Candidate attachments — resumes, cover letters, certifications
3. Companies — client records with billing contacts
4. Contacts — individual contacts at each company
5. Job orders — active and recently filled (last 12 months)
6. Placements — all placements with fee and date data
7. Notes/activities — at least the last 12 months of activity

Common export pitfalls

Custom fields export as IDs, not labels. Bullhorn stores dropdown values as numeric IDs internally. When you export, you may get "5" instead of "Healthcare." You will need Bullhorn's field mapping reference or a developer to decode these.

Attachments require separate handling. BDE exports metadata about attachments, but not the files themselves. You need the REST API or a manual download process to get the actual PDFs and documents.

Date formats vary. Bullhorn may export dates as Unix timestamps, ISO 8601, or US format depending on your instance configuration. Standardize everything to ISO 8601 (YYYY-MM-DD) before importing anywhere.

Character encoding issues. International names and special characters can break if your CSV files are not exported in UTF-8 encoding. Always verify encoding before importing.

Step 2: Map fields to your new system

Field mapping is where migrations succeed or fail. This is the step where you define how each Bullhorn field translates to the equivalent field in your new platform.

Create a mapping spreadsheet

Build a simple three-column spreadsheet:

| Bullhorn field | New system field | Notes | |---|---|---| | firstName | first_name | Direct map | | lastName | last_name | Direct map | | email | email | Validate format | | customText1 | specialty | Was used for recruiter specialty | | customFloat1 | target_rate | Hourly bill rate | | status | pipeline_stage | Needs value mapping (see below) |

Handle value mapping separately

Field mapping tells you where data goes. Value mapping tells you how the contents translate. Bullhorn's candidate statuses might be "Submitted," "Interview Scheduled," "Placed," and "Rejected." Your new system might use "Applied," "Interviewing," "Hired," and "Declined." Map each value explicitly.

Decide what to do with unmapped fields

Every migration has orphan fields — Bullhorn data that has no obvious home in the new system. You have three options:

1. Create custom fields in the new system to hold the data.
2. Concatenate into a notes field so the data is preserved but not structured.
3. Drop it if it is truly unused.

Option 2 is the safest default. You preserve the information without bloating your new system's schema.

Step 3: Import and validate

Run a test import first

Never import directly into your production environment on the first attempt. Use a staging or sandbox instance. Import a subset — say 100 candidates and 20 job orders — and verify:

• Names, emails, and phone numbers came through correctly.
• Custom fields mapped to the right places.
• Attachments (resumes, documents) are accessible and intact.
• Dates are correct (not shifted by timezone offsets).
• Relationships are preserved (candidates linked to the right jobs).

Validation checklist

| Check | What to verify | |---|---| | Record counts | Exported count matches imported count | | Required fields | No blanks in name, email, or company | | Duplicate detection | No records imported twice | | Attachment integrity | PDFs open correctly, not corrupted | | Date accuracy | Placement dates match Bullhorn originals | | Custom field values | Dropdowns show labels, not IDs | | Relationship links | Candidates tied to correct placements |

Fix issues and re-import

You will almost certainly find problems on the first pass. That is expected. Fix the mapping, clean the source data, and run the import again. Most teams need two to three iterations before the data is clean.

Step 4: Parallel run for one week

This is the step most agencies skip, and it is the step that prevents disasters.

For one week, run both systems simultaneously. Your team continues working in Bullhorn as the primary system while also logging new activity in the new platform. At the end of the week, compare:

• Are all new candidates captured in both systems?
• Are pipeline stages consistent?
• Are there any workflows that do not have an equivalent in the new system?

The parallel run is your safety net. If something is fundamentally broken, you have not yet cut over. You can fix it without any business disruption.

What to watch for during the parallel run

Workflow gaps. Maybe your team relies on a Bullhorn automation (like auto-sending a rejection email when a candidate is moved to "Not Selected") that does not exist in the new system yet. Identify these gaps now, not after go-live.

Speed and adoption. Are recruiters able to complete their daily tasks in the new system without excessive friction? If a task that took 2 clicks in Bullhorn takes 8 clicks in the new platform, that is a problem worth solving before go-live.

Integration dependencies. If you use Bullhorn integrations (VMS, job boards, background check vendors), verify that the new system has equivalent connections or that you have a workaround.

Step 5: Go live

Once the parallel run passes without major issues, schedule the cutover.

Go-live day checklist

1. Final data sync. Export any records created in Bullhorn during the parallel week and import them into the new system.
2. Disable Bullhorn logins. Do not delete anything — just restrict access so the team cannot accidentally use the old system.
3. Notify your team. A clear, one-paragraph message: "Starting today, all work happens in [new system]. Bullhorn is read-only for reference."
4. Designate a point person. One person handles all migration questions for the first week so issues get resolved quickly.
5. Keep Bullhorn accessible (read-only) for 90 days. You will need to reference historical data during the transition period.

Timeline expectations

| Agency size | Typical migration timeline | |---|---| | 1-5 recruiters | 2 weeks | | 6-15 recruiters | 3 weeks | | 16-30 recruiters | 4 weeks | | 30+ recruiters | 4-6 weeks (phased rollout recommended) |

These timelines assume one dedicated migration lead and no major custom development.

Rollback planning

Every migration should have an exit ramp. If go-live reveals a critical issue — data corruption, a missing integration, or team-wide adoption failure — you need a plan to revert.

Your rollback plan is simple: Bullhorn is still there. As long as you kept Bullhorn active (read-only) and performed a final data sync before cutover, you can re-enable Bullhorn logins and resume operations within hours. The new system becomes the staging environment while you resolve the issue.

The key is to never delete your Bullhorn data or cancel your Bullhorn subscription until you are at least 90 days past go-live and fully confident in the new system.

How Winnow simplifies the process

Winnow Career Concierge was built by people who have lived through CRM migrations. The recruiter platform includes a one-click import feature specifically designed for agencies leaving Bullhorn and other legacy CRMs.

Automated field mapping. Winnow recognizes standard Bullhorn export formats and auto-maps the most common fields. You review and approve the mapping instead of building it from scratch.

Attachment handling. Upload your candidate attachments in bulk. Winnow's resume parser extracts structured data from each document automatically, so you get clean, searchable candidate profiles from day one.

Pipeline translation. Winnow maps Bullhorn pipeline stages to its own workflow stages and lets you customize the mapping before import.

Validation dashboard. After import, a validation report shows record counts, flagged issues, and data quality scores so you know exactly where to focus cleanup efforts.

If you are evaluating alternatives to Bullhorn, the Bullhorn comparison page breaks down the specific differences in pricing, features, and workflow complexity.

Common questions

Will I lose my activity history? Not if you export it. Bullhorn's REST API provides access to notes, emails logged against records, and call logs. Import these as activity records in your new system. The data may be structured differently, but it will be preserved.

What about integrations with VMS platforms? This depends on your new system. Verify VMS compatibility before committing to a migration. If your agency relies on Bullhorn's VMS integrations (Fieldglass, Beeline, etc.), this is a non-negotiable requirement for any replacement.

Can I migrate in phases? Yes, and for larger agencies, phased migration is recommended. Start with one team or one office. Let them stabilize for a week, then migrate the next group. This limits blast radius if issues arise.

What if I have years of historical data? Migrate the last 12 to 24 months of active data. For older records, export to CSV and store as an archive. Most agencies find they never need to reference placements from five years ago in their daily workflow.

The bottom line

Migrating off Bullhorn is not the nightmare it is often made out to be. The agencies that struggle are the ones that skip the audit, rush the field mapping, or go live without a parallel run. Follow the six steps in this guide, give yourself a realistic timeline, and you will come out the other side with cleaner data and a system that actually fits your team's workflow.

The hardest part is making the decision. The migration itself is just project management.