Data migration
Ten years of history is not a reason to stay.
Getting candidates, clients and placements out of JobAdder, Vincere or Bullhorn is real work — and it is work we do, not a spreadsheet template we hand you with our best wishes. Documents come across on the JobAdder connection; no spreadsheet export can carry a CV.
Fear keeps more agencies on bad software than price ever does. Not one of the major recruitment systems lets a departing customer take their data cleanly — full exports sit behind signed request forms, paid engagements and 30-day windows, and what you can get yourself is a capped CSV with the notes and documents missing. That is the whole reason switching feels impossible. So we made it our job rather than yours.
Three systems, three different exits.
What each one lets you take, and what we do about it. No guessing — this is what their own documentation says.
JobAdder
Live connectorGetting your data out. The API is the good path, and it is the only one of the three where a placement carries both the pay rate and the charge rate. That is the field every CSV export drops, and the one you cannot rebuild from memory.
What we do. Connect JobAdder with OAuth and we read companies, contacts, candidates, jobs, applications, placements with their rates, hotlists, notes and CV attachments — on an hourly sync, not a one-off dump. You can leave that connection running for as long as you want it.
Vincere
Export and loadGetting your data out. Self-service export is a list view capped at 5,000 records at a time, with vendor-fixed columns — so custom fields never come out that way. A full export including CV documents is a chargeable professional-services engagement: submit a form, take a quote, wait about ten business days.
What we do. We take whatever you can get out — the capped CSVs, or the paid export if you buy it — and load it through the import workbench, mapping their columns to ours field by field and showing you every row's verdict before anything is written.
Bullhorn
Export and loadGetting your data out. List-view exports cap at 5,000 to 20,000 records depending on the entity, and rich-text fields do not export at all, so formatted notes are lost on that path. A full backup with your attachments needs two of your named contacts to sign a request, is limited to one every 30 days, and only the final one carries every file.
What we do. Same workbench, same mapping and preview step. Get the request in before your contract lapses — assume no export entitlement survives it — and we will tell you which files to ask for.
Nothing is written until you have seen every row.
Whatever comes out of your old system lands in an import workbench, not a black box. Known exports are recognised and pre-mapped. Everything else — and Bullhorn and Vincere exports are deliberately in this group, because their columns change shape per tenant — gets a best-guess mapping from a synonym table that you correct from a dropdown. A CSV is never rejected for having the wrong header names.
Then the whole file is read and classified before a single record is created: new, update, likely duplicate, junk, or error. You look at that, tick rows in or out, and confirm. Only then does anything touch your data.
- Clients, contacts, candidates, job orders, placements and deals
- Placeholder emails and repeated header rows caught, not imported
- Errors reported per row, quoting the spreadsheet row number
- Re-run the corrected file and it updates rather than duplicates
What comes across, and what nobody can give you.
The second list matters more than the first. You should hear it from us now, not discover it the week after go-live.
Your book, intact
- Client companies — phone, website, address, industry, and NZBN or ABN
- Client contacts, attached to the right company by name
- Candidates — contact details, address, status, source and skills
- Job orders — client, headcount, dates, work type, and both rates
- Placements as live assignments, carrying the pay rate and the charge rate
- Deals, landing on your sales pipeline at the right stage
- Your legacy record IDs, namespaced by the system they came from, so a Bullhorn 12345 and a JobAdder 12345 never become one person
- CVs and documents — on the JobAdder connection, drained straight into each candidate's file
What you will have to let go
- Rate history — what a rate used to be before somebody changed it
- Timesheet history, from any of the three
- Email threads; nobody exports a mailbox
- Files on a spreadsheet path — a CSV cannot carry a CV, so documents come across on the JobAdder connection or not at all
- Columns with no matching field. If we do not model it, it does not come through — and you see exactly which columns those are before you commit, not after
- Worker and client portal logins — those are re-issued from Workhr, and should be
- Right-to-work and compliance clearances. A tick in the old system does not become a clearance here; Workhr re-checks visa and document status itself, because a migrated tick is not evidence
Six steps, in this order, for a reason.
Import order does not decide whether a load succeeds. It decides whether your client records arrive whole or as name-only stubs.
We agree what has to come across, and give you the list of exports to request from your current vendor — with their caps and lead times, so nothing is discovered late.
The files go into the workbench and you say which system they came from. Known exports are pre-mapped; everything else — Bullhorn and Vincere included — gets a best-guess mapping you correct from a dropdown. No CSV is bounced for having the wrong header names.
Nothing is written yet. Every row is read and given a verdict first: new, update, likely duplicate, junk or error. Placeholder emails and repeated header rows are caught here rather than quietly imported.
You read the verdicts, tick rows in or out, and confirm. That click is the first moment anything touches your candidates, clients or placements.
Clients load first, then contacts, candidates, job orders and placements — so children attach to full records, not name-only stubs. Failures come back as a file quoting the spreadsheet row number; fix the sheet, re-upload, and it updates rather than duplicates.
Then the landing gets checked before you go live: row counts against the source, clients that arrived hollow, people with no email, and a rate spot-check on real placements. A wrong rate still looks like a plausible number, so it is read by a person.
You may not have to leave at all.
JobAdder is the one of the three we hold a live connection to, and it runs both ways. Your consultants keep placing in JobAdder; Workhr reads the placements and runs everything after — rostering, site sign-in, timesheets, pay and bill — and sends worker availability and placement rate changes back up. Pushing application stage moves back the other way is built, and it is switched on per tenant rather than by default, so ask for it at setup. It reconciles every hour and reacts to JobAdder’s own events in between.
Because both systems stay live, both can edit the same record. Workhr does not resolve that by taking the vendor’s word for it: where only you moved a field your edit stands, where only JobAdder moved it theirs applies, and a genuine clash is raised for a person to settle rather than overwritten. That is what makes coexistence a real answer instead of a stalling tactic.
- Companies, contacts and candidates, kept in step
- Jobs, and applications landing at the right pipeline stage
- Placements as assignments, with pay and charge rates
- CVs and documents drained into each candidate’s file
The questions you should be asking.
- Do I have to leave JobAdder to use Workhr?
- No, and most agencies should not start there. Workhr runs alongside JobAdder on a live connection: your consultants keep placing in JobAdder, and Workhr picks up at the placement to roster the shift, run site sign-in, capture the timesheet and move approved hours to pay and bill. Plenty of agencies will never move off it. If you later decide to, your data is already in Workhr and there is no migration project left to run.
- Is there a live integration with Bullhorn or Vincere?
- No, and we would rather say so than let you find out later. There is no Bullhorn connector and no Vincere connector in Workhr. What we do for those two is a structured export and load: you get your files out, we map their columns to ours, every row is classified and shown to you before anything is written, and duplicates are flagged for a person to decide. It is the same workbench a JobAdder or HubSpot export file runs through — not the live JobAdder connection, which is a separate pipeline. What it is not is a live API sync.
- Why is there no automatic format pack for Bullhorn or Vincere?
- Because their list-view exports change shape depending on how the tenant is configured. A signature that matched most of them would confidently mis-map the rest and stamp it 'recognised', which is worse than no detection at all. Their files get a best-guess mapping from a synonym table instead, and you correct it from a dropdown before it runs.
- What happens to columns Workhr has no field for?
- They do not come through, and you will see that before you commit rather than discover it afterwards — the mapping screen shows every column and where it is going. What is preserved deliberately is your legacy record ID: it is kept against the Workhr record and namespaced by source system, so re-running the same export updates the same records and two systems' id 12345 never collide. If a field genuinely matters to your desk, tell us at scoping — most of the time the answer is a field, not a workaround.
- What if the import goes wrong?
- The design assumes it will, at least once. Nothing is written until you have seen every row's verdict and confirmed. After that, failures come back as a downloadable file quoting the spreadsheet row number, so you fix the sheet rather than the database — and re-running the corrected file updates the records it already created instead of duplicating them. One bad row does not discard the 49,999 good ones.
- How big can a file be?
- Up to 25 MB and 50,000 rows per file, which comfortably covers the batches your old system will let you export in one go — Bullhorn caps a list export at 5,000 to 20,000 records, Vincere at 5,000. Split books arrive as several files and land in the same place.
- How long does a migration take?
- The long pole is almost never us — it is your current vendor's export queue. A Bullhorn full backup is limited to one every 30 days; a Vincere professional-services export is quoted and then delivered in about ten business days. Start the request early, because you should assume export entitlements do not survive the end of your contract. We agree the schedule once we have seen what you can actually get out.
- What does it cost?
- There is no setup fee and no minimum term, and bringing your data across is included — we load it for you rather than handing you a template and wishing you luck. If your old vendor charges for the export itself, that invoice is theirs, not ours, and we will tell you when one is coming.
- Can we run both systems for a while?
- With JobAdder, yes — that is the normal way in, and the connector is built for it rather than tolerating it. Where both systems have touched the same field, Workhr does not silently take the vendor's word for it: it keeps your edit, applies theirs where only they moved, and raises the genuine clashes for a person to settle. With Bullhorn and Vincere you can keep both open through the load and the checks, but nothing holds the two in step, so pick a cutover date rather than running in parallel indefinitely.
Why it matters for your desk
Your files, mapped and imported by us, not a template and good luck.
Every row is classified and shown to you before it becomes a record.
A wrong rate still looks like a plausible number, so it gets read, not assumed.
Send us one export file.
We’ll map it, load it into a sandbox and show you your own book running in Workhr before you commit to anything.