Bring your database across, properly

Moving a working agency database off an established system is a different problem from loading a spreadsheet. A mature Bullhorn or Vincere tenant holds custom fields nobody documented, attachments hanging off records in several places, ownership and desk assignments that determine commission, consent history that legally has to survive the move, years of activity records, and placements with rates, splits and guarantee terms attached.

A generic importer handles the first ten percent of that: names, emails, phone numbers, titles. It fails on exactly the accounts worth migrating, because the value of a fifteen-year-old database is not in the contact rows. It is in the relationships, the history and the attachments, and those are the parts a column mapper cannot infer.

The failure is quiet, which is what makes it dangerous. The import reports success, the row count looks right, and six weeks later somebody discovers that the notes are gone and every record is owned by the person who ran the import.

A migration off an established incumbent is scoped and run as a paid, founder-led project. Someone from our side looks at your actual export, maps the custom fields with you, decides with you what is worth bringing and what should be left behind, runs a test migration into a sandbox tenant, and gives you a reconciliation before anything touches your live data.

It is paid because it takes real work and because free migrations are done badly by whoever has a spare afternoon. It is founder-led because the person doing it needs to be able to make judgement calls about your data and be accountable for them. We would rather charge for it and get it right than include it as a checkbox and hand you a broken database on day one.

The parts that need deciding, one by one: candidates and their custom fields; clients, contacts and the relationships between them; jobs and requisitions, open and historic; attachments including resumes, right-to-work documents and signed agreements; record ownership and desk assignment; consent basis and its capture date; activity and note history, and how far back it is worth carrying; and placements with their fees, splits and guarantee terms.

Each of those is a decision rather than a default. Carrying twelve years of activity history costs something and is sometimes not worth it; consent history is almost never optional; ownership almost always needs correcting during the move rather than after. A scoping conversation is where those decisions get made deliberately instead of by whatever the exporter happened to include.

Every migration runs into a sandbox tenant first. You get counts by object, a sample of records to inspect against the source system, a list of what was skipped and why, and a written reconciliation. Nothing goes into your live tenant until you have looked at the test and agreed it is right.

Cut-over is planned rather than assumed. There is usually a delta load for the records that changed while the migration ran, a agreed period of parallel running, and a point at which the old system becomes read-only rather than being switched off. Agencies that skip the parallel period are the ones who discover a missing field during a live client conversation.

Four questions separate a real migration capability from a marketing claim. Does the attachment history come across, or only the latest resume? Does record ownership survive, or does everything arrive owned by the admin who ran it? Does consent basis and its capture date come across, or is your compliance position quietly reset? And is there a test run into a sandbox with a reconciliation you can check before anything is written to live?

Ask us those questions too. The honest answer to the first three is that it depends on what your current system will export and what you decide is worth bringing, which is why the conversation happens before the money rather than after the migration.