Getting your data out of Bullhorn intact

Structured records move well. Candidates, contacts, companies and jobs with standard fields transfer with high fidelity, because both systems model them similarly. Custom fields move if somebody maps them by hand, which is slower than it sounds because half of them will turn out to mean something different from their label.

Notes are the first thing to degrade. The text usually arrives; the authorship and the original timestamp frequently do not, or arrive as a single import user with today's date. That is the metadata that makes a note evidential rather than anecdotal, so decide in advance whether you will prefix each note with its original author and date in the body text as a preservation measure.

Attachments are the second. They are stored separately, they are large, and export tooling often has limits that produce partial transfers with no error. Activity streams, email associations and consent history are the third: they are commonly not exportable in any usable structure, because they were never separate objects in the same way in both systems.

Record ownership drives commission, visibility and reporting, and it is where migrations quietly change the business. If a departed recruiter owns four thousand candidates, importing that ownership faithfully recreates a dead desk in a new system. Reassigning them all to one manager creates a different distortion. Decide the rule explicitly, write it down, and tell the desk before go-live rather than after somebody notices.

Placements carry financial history: fee, rate, start date, end date, guarantee window, extensions, rebate obligations. Migrate the ones still commercially live with full fidelity, because those are the records a dispute will turn on. Historical closed placements can often move as a flatter summary, which is a legitimate trade if it is a decision rather than an accident.

Submittals matter more than firms expect. They are what your conversion reporting is computed from, so if they do not come across, your new system starts with no history and every ratio reads as new for a year.

Under UK and EU rules, and increasingly under US state law, the lawful basis for holding a candidate record is part of the record. If consent history does not migrate, you arrive in the new system holding personal data with no recorded reason for holding it.

There are three defensible responses and they are all decisions you make with your own counsel, not choices a vendor can make for you. Re-permission through a campaign before or shortly after migration. Carry the records under a basis your advisers agree applies, with the reasoning documented. Or do not migrate the records at all, which for a database with a long dormant tail is often both the cheapest and the cleanest option.

What you should not do is import everything silently. The obligation travels with the data, and a migration is the one moment where a firm can see the whole database at once and act on it.

Most long-lived databases contain the same person several times: sourced by two recruiters, applied twice under different email addresses, imported once from a job board. Migration is the natural point to fix that, because you are touching every record anyway.

Deduplicate on the way in rather than afterwards. That means agreeing a match rule before the test load, deciding which record wins a conflict and on what basis, and deciding what happens to the losing record's notes and attachments. Merging should preserve both histories rather than discarding the loser, because the discarded record is the one with the note explaining why the client rejected them.

Expect a manual review queue. An automatic rule will handle the clear cases and should refuse the ambiguous ones. A migration that silently merges two different people with the same name creates a problem far worse than the duplicate it removed.

Read your agreement before you start, specifically the notice period, the auto-renewal date and the data-retrieval window after termination. Firms routinely discover that notice had to be given ninety days before a renewal that has now passed, which means paying for another year alongside the new system.

Ask what your export entitlement actually includes, in writing, and whether it is self-service or a chargeable service request. Ask how long the data remains retrievable after the contract ends. Then take your export earlier than feels necessary and keep it, because retrieval gets harder once you are a former customer.

Time the cutover around the billing cycle rather than the calendar. Cut over just after a pay or invoice run, not in the middle of one, and avoid the week a large client's process peaks.

The pattern that works is a test load, a reconciliation, a fix cycle, then a final delta load over a weekend. The test load uses a representative slice, not the easy records. Reconciliation compares counts and spot-checks the extreme records you identified in the inventory. The fix cycle addresses what the reconciliation found, and it usually takes two rounds.

During the final load, freeze writes in the old system. Any record created during the freeze goes into a short manual list to be re-entered afterwards, which is far cheaper than trying to reconcile a moving source. Publish the freeze window in advance so the desk plans around it.

On the first working day, the priority is not training, it is confidence. Have someone available to answer where is my candidate, and have the reconciliation counts ready to show. A desk that believes its data arrived will use the system; one that suspects data is missing will keep a private spreadsheet, and that habit is very hard to reverse.

Everything above is why Surhires runs early Bullhorn migrations as paid, founder-led concierge projects rather than shipping an importer button. A generic importer handles standard fields and then produces a result that looks finished, which is the most dangerous possible outcome. The parts that need judgement are custom-field meaning, ownership rules, duplicate conflicts, consent basis and what to do with orphaned notes.

The migration feature page explains the scope, what is included and what is not. It is deliberately a service today rather than a self-service tool, and it is described that way rather than as automation that does not exist yet.

If you are evaluating and want to know whether your specific data shape will move, the useful first step is the inventory in the first section of this page. It is worth producing whichever system you end up choosing.