Move off Bullhorn without losing the history that makes the database worth moving

The candidate and contact tables are the easy part, and they are perhaps a fifth of the value. Underneath them sit custom fields that were added over years by people who have left, notes running to hundreds of thousands of rows with authorship and timestamps that matter, and attachments in several formats where the original resume, a formatted version and a right-to-work document all hang off the same record.

Then there is the relational history: candidate ownership and the split arrangements behind it, activity streams, job orders with their own custom fields, submittals tied to specific contacts on specific dates, placements with rates, fees, guarantee windows and extension records, and the email associations that connect a thread to a candidate, a contact and a job order at the same time.

And there is the mess. Duplicate candidates created by four recruiters over six years, records with conflicting ownership, notes attached to the wrong object, custom fields holding three different meanings depending on which year they were populated. A migration plan that does not have a position on the mess is not a plan.

A generic importer works fine on a two-year-old database with four thousand candidates and no customisation. It fails on the ten-year-old agency with two hundred thousand records, sixty custom fields and a placement book, which is exactly the account worth migrating and exactly the account that cannot afford to lose anything.

The failures are predictable. Notes arrive without authors, so every entry looks like it was written by the migration account and the audit trail is gone. Attachments arrive detached from the right record, or the second and third documents on a candidate are dropped because the importer assumed one file. Ownership collapses to whoever ran the import, and every commission calculation downstream is wrong.

Duplicates are the quiet one. An importer that does not merge on the way in creates a database that is worse than the one you left, because now every duplicate exists twice with half the history on each copy. Merging afterwards is significantly harder than merging during the load, and by then people are already working in the system.

It starts with a discovery pass over your tenant: object counts, custom field inventory, attachment volume and formats, note volume, user list and ownership map, and a sample of records from each era of the database. That produces a scope document rather than an estimate, and the scope document is where the argument happens, which is the right place for it.

The statement of work then names, explicitly, which objects are in scope and which are out. Out of scope is written down as clearly as in scope, because the failures in this kind of project are almost never about what was promised and almost always about what nobody said would not be there. Field-level mapping is agreed the same way, including what happens to a legacy field that no longer has a meaning anybody can reconstruct.

Only then does anything move. The load runs into a sandbox tenant that mirrors your production configuration, your people work in it against real records, and the issues that surface there are the ones you would otherwise have found on the Monday after cutover.

After the test load, you get a reconciliation report rather than a confirmation email. It compares counts on both sides object by object, lists every record that did not transfer with the reason, shows how duplicates were resolved and how many merges occurred, reports attachment counts and total bytes moved against the source, and names every field that was dropped, defaulted or transformed.

Discrepancies are expected and they are the point. A source system with two hundred thousand candidates will have records that cannot be moved cleanly, and a report that shows a perfect match is usually a report that was not looking hard enough. What you should judge is whether every gap has an explanation you accept.

Sign-off is yours and it is explicit. Cutover does not happen because a migration window was booked; it happens because you have read the reconciliation report, worked in the sandbox and said yes in writing.

Until cutover, your Bullhorn tenant is untouched and remains your system of record. Nothing in this process writes to it. If the sandbox work says the migration is not ready, the answer is to fix the mapping and run it again, and the cost of that decision is time rather than data.

At cutover we keep the sandbox state, a full export of what was loaded and the complete migration log, so a problem discovered in the first weeks can be traced to the record, the field and the transform that caused it. Recovery is a corrective run against a known state rather than a reconstruction from memory.

The limit is worth naming. Once your team has been working in the new tenant for a fortnight, going back means losing that fortnight of work, because the two systems have diverged. The rollback position protects the migration, not an indefinite right to change your mind, and any vendor who tells you otherwise is describing something that does not exist.

The cost driver is not record count, which is the thing everybody asks about first. It is the number of custom fields whose meaning has to be reconstructed, the number of legacy conventions in the data, the attachment volume, and how much of the history you insist on preserving exactly. A clean two-hundred-thousand-record database can be simpler than a messy twenty-thousand-record one.

In effort terms, discovery runs days rather than weeks, mapping is the part that consumes the most calendar time because it needs decisions from people on your side who know why a field exists, the test load and reconciliation take a further pass, and there is usually a second test load after the first report changes somebody's mind. Cutover itself is short. The elapsed time is dominated by your review cycles, not by our processing.

We are not going to publish a price on this page. A migration quote that is real depends on the discovery pass, and a number printed before anybody has looked at your tenant is either a guess that will move or a floor priced for the simplest possible case. Ask for the scoping conversation and we will quote against what is actually there.