Migrating from Bullhorn: What Transfers, What Breaks, How Long It Takes

Moving an agency off Bullhorn takes 4 to 6 weeks for a team of 5 to 20 recruiters, and it does not need a day of downtime. Candidates, contacts, companies, jobs, submissions, placements, notes and CVs transfer; undocumented custom fields, email threads, automations and saved searches generally do not. The sequence that works is a read-only audit, then extraction and verification, then 2 weeks with both systems live, then a cutover that is really just a permissions change. What blows the timeline is almost never the data.

I ran a recruitment agency before I built Pickr, and we changed systems twice, once badly. The mechanical part was the easy part both times. This article is about the mechanics rather than the choice of vendor: what comes across, what does not, in what order, and what makes it take twice as long as it should.

What actually transfers out of Bullhorn

The commercially important objects move cleanly, because every serious ATS has the same shapes: candidates, contacts, companies, jobs, applications and submissions, placements with their dates and fee values, notes attached to any of those records, and stored documents including CVs.

That set is not a compromise. It is your commercial history — who you placed, where, for how much, and what you wrote about them at the time. Carry those six object types across and you have not lost the business.

Plan for a residue of failures on the first pass rather than a clean sweep. In the two moves I have been through, the misses were a low single-digit share of candidate records and they clustered into the same three causes: encoding damage in names, the same person sitting under three IDs because three recruiters added them separately, and documents that were linked from a network drive instead of uploaded. All three are findable before cutover if someone goes looking. None of them is findable afterwards except by a recruiter complaining.

Object	Transfers cleanly	Common failure
Candidates	Yes	Duplicates, encoding damage in names
Contacts and companies	Yes	Contacts orphaned from dead companies
Jobs and submissions	Yes	Custom pipeline stages need mapping
Placements	Yes	Fee splits across multiple recruiters
Notes	Yes	Author attribution when users were deleted
Documents and CVs	Usually	Links to external drives break

What does not survive an ATS migration

This is the part vendors are vague about, so here it is plainly.

Custom fields nobody documented. Every agency older than 5 years carries dozens of custom fields and actively uses maybe a third of them. Nobody can say what Source_Detail_2 means, because whoever added it left years ago. You cannot map what you cannot explain. Export the lot to a flat archive file, migrate the ones you can define, and let the rest go.

Email threads. Bullhorn's email integration sits on top of your mail server, and the mail itself lives outside the ATS records. Threaded correspondence rarely arrives in readable shape. In practice your email history stays in your email, which is where you were searching it anyway.

Automations and workflow rules. In the agency instances I have looked at, a meaningful share of the configured automations had quietly stopped firing and nobody had noticed. Porting them is the wrong instinct. Rebuild the few that matter in the new system and watch each one fire once before you trust it.

Saved searches, dashboards and per-user layouts. These are preferences, not data. Recruiters re-create the two they actually use inside a week.

How long does a Bullhorn migration take, week by week

Four phases. Compressing them is where the horror stories come from.

Phase 1 — read-only connection, week 1. Connect to the current system without writing anything back to it. Pickr can connect to an ATS you already run read-only and audit what is in there before anything is committed, which turns "20 years of history" from an anxiety into a set of counts you can argue about. That connection, and the import of hiring history that follows it if you do move, is what the ATS migration service covers.

Phase 2 — extract, map and verify, weeks 2 to 3. Records come across field by field, and then you verify, which is the step people skip. Pick 20 records you know personally: your 5 biggest placements, 3 candidates with messy histories, a client with several contacts and a split fee. Open each one in both systems side by side. If those 20 are right, the rest of the database probably is. If 2 of them are wrong, you have found a mapping bug affecting thousands of rows while it still costs an afternoon to fix. The import mechanics themselves sit under data import.

Phase 3 — parallel running, weeks 4 to 5. Both systems live. All new activity goes into the new one; the old one stays open read-only for lookups. 2 weeks is the right length — long enough that every recruiter hits their normal week twice, short enough that nobody settles into the split. Be honest with the team about the cost, because it is a real one: for those 2 weeks people check two systems for the same answer and it is irritating every time. Before the window closes, run a delta import of everything created inside it.

Phase 4 — cutover. Write access to the old system goes off. Do it on a Monday, not a Friday, so problems surface while everyone is at their desk. Keep the old contract alive in read-only for 60 to 90 days; it costs a little and it removes the last argument against moving. Move the roles sitting at offer stage last — a candidate mid-offer is the one record where a mapping error costs money rather than time.

Downtime across that sequence is zero. There is no moment when a recruiter cannot look something up.

What makes a migration take longer than 6 weeks

4 to 6 weeks is normal for 5 to 20 recruiters. For 20 to 40 recruiters, or with any of the following, budget 6 to 10 weeks.

Multiple legacy databases. Two offices that never merged their data. Every duplicate has to be resolved by a human who knows both markets, and no importer decides that for you.

Nobody accountable on your side. The largest single predictor of a slow migration is that no one at the agency can say "drop that field" without convening a meeting. Name one person and give them an hour a day.

Heavy custom-field use. Above roughly 25 active custom fields, mapping stops being mechanical and becomes a run of judgement calls.

Integrations pointing at the old system. Job board postings, calendar links, invoicing exports, anything with a webhook into the old ATS. Individually small, collectively the thing that slips a week.

Your two busiest weeks. Not because the data work conflicts, but because nobody has 90 minutes for training while they are closing.

Will your recruiters actually use the new system

This is the fear worth taking seriously, and it is not really about buttons.

Recruiters resist a new system when it asks them for more typing than the old one. That is a rational response to most migrations, and no amount of training argues with it. The only thing that works is the new system doing work the old one did not.

Pickr is the AI-native recruiting platform that scores every candidate on evidence of skills rather than keyword matches, including adjacent and transferable ones. Interviews are transcribed, and scorecards arrive pre-filled with evidence mapped to each criterion, so an interviewer edits a draft instead of facing an empty form days later. What happened to the people a client actually hired feeds back into how the next candidates are evaluated, which is the one thing a migrated archive cannot do on its own. For agency work, multi-client pipelines, client portals and placement tracking are native rather than permission workarounds, and interviewer and hiring-manager seats are free, so the client-side people who only ever leave a verdict do not appear on the invoice.

Two honest caveats before you plan any of this. Pickr does not publish list prices, so you cannot build the business case off a website and will have to have the conversation. And if your desk runs on contract and temp volume — timesheets, pay and bill, VMS feeds — the back office is the reason you are on Bullhorn, and nothing above outweighs it. Stay, and spend those 6 weeks on your process instead. For the feature-by-feature version rather than the migration version, the Pickr and Bullhorn comparison is the one to read next; if you are still deciding whether to move at all, the Bullhorn alternatives roundup is the better starting point.

Candidate data sits in Frankfurt, Germany, Pickr is built in Austria, a DPA is included, and personal data is redacted from AI prompts by default. In the German-speaking market that question usually arrives before the migration question does.

Is the migration worth doing at all

Your history transfers. Candidates, contacts, companies, jobs, placements, notes and documents all move. What does not move — undocumented custom fields, email threads, dead automations, saved searches — is mostly what you had stopped using. Audit read-only first, verify 20 records you know by heart, run 2 weeks in parallel, cut over on a Monday, and keep the old system readable for 90 days. 4 to 6 weeks, no downtime.

So the data is not the real question. The question is whether the system you move to does anything the old one did not. If the honest answer is no, stay where you are and keep the 6 weeks.