Bullhorn to Avionte migration requires restructuring relational staffing data across incompatible schemas. CSV exports drop relationships, the Bullhorn API caps at 1,500 req/min, and Avionte has no custom object equivalent.
A CTO-level technical guide to migrating staffing data from Bullhorn to Avionte BOLD, covering API constraints, object mapping, rate limits, and real failure modes.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Bullhorn's Opportunity entity has no direct equivalent in Avionte BOLD
If your agency uses Opportunities for sales pipeline tracking, that data must be flattened into notes, exported to a separate system, or abandoned. Plan this decision early. Similarly, if you heavily utilize Bullhorn's custom objects (e.g., tracking specialized certifications in a standalone table), you will need to flatten this data into custom fields on the Avionte Talent profile — or accept losing it.
Bullhorn's BhRestToken has a default idle timeout of approximately 10 minutes
For long-running extraction jobs, implement a background token-refresh loop rather than refreshing only on 401 responses. Generating a new token for every request will flag your account and throttle your API access.
The Avionte CreateTalent API checks for duplicates using SSN first, then Email, then
The Avionte CreateTalent API checks for duplicates using SSN first, then Email, then First+Last Name. If you're migrating records that share email addresses (common in staffing when a candidate re-applies through different channels), plan your dedup strategy before loading.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope candidates, pipelines and the compliance obligations that come with them.
Objective Agreed scope across candidates, applications, jobs and interview history, with legal signed up on retention.
Keep these open
-
Inventory every object in Bullhorn
Count candidates, applications (a candidate can have many), jobs and requisitions, interviews, scorecards, offers, and resume files. Applications and scorecards usually outnumber candidates several times over, and resume files dominate storage.
Data Profiler Get real record counts instead of estimating from memory -
Settle retention and consent with legal
Candidate data is heavily regulated: GDPR right-to-erasure, EEOC/OFCCP record-keeping, and per-region retention windows that conflict with each other. Decide what may be migrated at all before you scope anything else — this frequently shrinks scope substantially.
Migrating candidate records whose consent has lapsed or whose retention window has expired creates a new compliance breach in the target system.
-
Map the hiring pipeline and agree the target stages
Document every job's pipeline, stage, and rejection reason, then agree the Avionté model with talent leadership. Stage definitions drive every funnel metric you report, so changing them silently rewrites your hiring analytics.
-
Catalogue integrations and the job-board estate
List job boards, careers-site integration, HRIS, background check, assessment platforms, calendar and email. The careers site and job boards are customer-facing, so their cutover needs its own plan and its own testing.
-
Build the business case and choose the window
Model licence delta, effort and recruiter productivity dip. Time the window against your hiring cycle: a migration during peak graduate recruitment or a hiring surge will fail on people, not technology.
Vendor Evaluator Score Avionté against alternatives on weighted criteria -
Record count comparison
total records per entity type in Bullhorn vs. Avionte.
Bullhorn → Avionté specifics
- Integrated back office
- Avionte BOLD combines front-office ATS/CRM with payroll, billing, and tax management in a single platform. Bullhorn requires third-party back-office integrations (1Staff, Tempworks) that add cost and integration maintenance.
- Cost structure
- Bullhorn's per-user pricing plus add-on costs for Automation, Marketplace integrations, and back-office connectors can push total cost of ownership significantly higher than Avionte's bundled model.
- Simplicity over extensibility
- Bullhorn offers deep customization (custom objects, Data Hub, extensive API). Some agencies don't need that complexity and prefer Avionte's more opinionated, streamlined workflow.
Don't move on until
- Counts confirmed for candidates, applications, jobs and offers
- Retention and consent obligations confirmed with legal
- Hiring-stage model agreed with talent leadership
02 Data Audit Audit candidate data with compliance sitting next to you.
Objective Profiled exports with duplicates, expired records and resume files all quantified and triaged.
Keep these open
-
Export and profile candidates, applications and jobs
Profile each object separately and reconcile against API counts. Watch the candidate-to-application ratio: a mismatch usually means applications have been silently truncated by pagination.
Data Profiler Profile the Bullhorn export for nulls, outliers and type drift -
Quantify duplicate candidates and agree survivorship
The same person applies repeatedly over years with different emails and name spellings. Measure the duplicate rate and agree survivorship rules — which record wins and what happens to the application history attached to the losers.
Merging candidates without agreed survivorship rules destroys application and interview history that you may be legally required to retain.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Identify records outside their retention window
Flag candidates whose consent has expired, who have exercised erasure, or who fall outside regional retention. Exclude them from scope and document the exclusion — you need to show the decision was deliberate.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Inventory resume files and attachments
Count files, total volume and MIME types, and check every attachment still resolves to a live URL. Expiring signed download URLs are the classic reason a resume migration completes with a large fraction of empty files.
Resume download URLs are often short-lived signed links. Fetch files close to load time or they will 404 mid-migration.
-
Verify relationship integrity
Confirm every application links to a live candidate and a live job, and every scorecard to a real interview. Orphaned applications produce a funnel report that does not tie to anything.
-
Clean, normalise and produce masked test data
Normalise emails, phone formats and locations, standardise timestamps to UTC, and generate a masked dataset for the sandbox. Real candidate data in a sandbox is a compliance breach in most jurisdictions.
PII Masker Generate a safe copy for sandbox and vendor testing -
Identify custom objects
in use: query Bullhorn's metadata API (/meta/Candidate?fields=*) to discover which customObject{#}s instances are active.
-
Map picklists
Bullhorn dropdowns often differ from Avionte's standard taxonomies. Document every picklist mapping.
-
Extract reference data first
Skills, BusinessSectors, Categories, Sources. These are lookup entities needed to resolve foreign keys.
Bullhorn → Avionté specifics
- Count records
- by entity type in Bullhorn: Candidates, ClientCorporations, ClientContacts, JobOrders, Submissions, Placements, Notes, Opportunities.
- Measure attachment volume
- file attachments (resumes, signed documents) can be the largest data payload. Size this early.
- Flag duplicate and stale records
- Bullhorn does not hard-delete most entities by default — isDeleted soft-delete flags must be filtered before export.
- /entity/{type}/{id}
- retrieves specific records by ID. Supports comma-separated IDs for batch gets.
- Authenticate
- complete the OAuth 2.0 flow, obtain BhRestToken and restUrl.
Don't move on until
- Duplicate candidate rate quantified with a merge policy agreed
- Records outside retention identified and excluded
- Resume and attachment inventory complete with total volume
03 Field Mapping Map the candidate-application-job triangle before anything else.
Objective A signed mapping covering objects, stages, rejection reasons, scorecards and EEO fields.
Keep these open
-
Map the candidate, application and job model
ATS platforms differ on whether a person or an application is the primary record. Establish this first: getting it wrong means one candidate becomes five, or five applications collapse into one, and the entire field map has to be redone.
Candidate-centric and application-centric models are not interchangeable. Confirm which Avionté uses before mapping any field.
Schema Mapper Match Bullhorn fields to Avionté by uploading both schemas -
Map pipeline stages and rejection reasons exhaustively
Enumerate every stage and rejection reason across all jobs, including retired values on historical applications, and map each explicitly. Unmapped rejection reasons are both a reporting gap and, in regulated hiring, a compliance one.
-
Decide EEO and diversity data handling
These fields are separately regulated and often legally required to be stored apart from the candidate record. Confirm with legal whether they migrate at all, and how Avionté isolates them.
EEO data usually cannot be migrated into ordinary custom fields without breaching the segregation rules that govern it.
-
Map interviews, scorecards and feedback
Structured scorecards rarely have a native equivalent. Decide whether to reconstruct them, flatten them into notes, or keep them only in the archive — and be explicit that flattening loses the ability to report on them.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Plan resume and file migration
Confirm size limits, MIME support and whether Avionté re-parses resumes on upload. Re-parsing can overwrite carefully curated candidate fields with worse machine-extracted values, so test it deliberately.
-
Set load order and freeze the spec
Users, then jobs, then candidates, then applications, then interviews and scorecards, then files. Keep source IDs in custom fields, then version and sign off the spec.
-
Build an ID mapping table
Bullhorn integer IDs → Avionte IDs (populated during load). This is the backbone of the entire migration.
-
Map picklist/status values
Bullhorn's candidate statuses, job statuses, and sources won't match Avionte's. Create an explicit mapping dictionary.
-
Flatten custom objects
serialize Bullhorn PersonCustomObjectInstance data into Avionte custom fields. If Avionte doesn't have enough custom field slots, decide what to drop.
Bullhorn → Avionté specifics
- Catalog custom fields
- map every customText, customInt, customFloat, customDate field to determine which carry real data vs. legacy/unused fields.
- Restructure Notes
- Bullhorn Notes are entity-agnostic (linked via personReference/jobOrder/placement). Avionte Activities live on the Talent record. Map Note → Talent Activity, preserving the original timestamp and author.
Don't move on until
- Candidate/application/job model mapped and reviewed
- Every stage and rejection reason explicitly mapped
- EEO and diversity field handling agreed with legal
04 Test Migration Pilot whole candidate journeys, not isolated records.
Objective A sandbox pilot where candidate journeys, funnel metrics and resume files all verify.
Keep these open
-
Configure the Avionté sandbox with the agreed pipelines
Create jobs, pipeline stages, scorecard templates, user roles and custom fields first. Loading applications before the stages exist puts every candidate in a default stage and invalidates the pilot.
-
Select complete candidate journeys as the pilot slice
Take 100-200 candidates with all their applications, interviews, scorecards and files — including repeat applicants, hires, rejections at every stage, and candidates on multiple jobs. Repeat applicants are where the model mapping actually gets tested.
-
Run the load in dependency order with logging
Jobs, candidates, applications, interviews, then files, logging each request against its source ID. Track file uploads separately: they fail for different reasons and at different rates than record writes.
-
Verify journeys and funnel metrics
Confirm each candidate sits at the right stage on the right job with their history intact, and that per-stage funnel counts match Bullhorn for the pilot jobs. Funnel mismatches point straight back to stage mapping.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Open every pilot resume and check re-parsing
Actually open the files rather than trusting the upload count, and check whether re-parsing has overwritten any candidate fields. A resume that uploaded as a zero-byte file still counts as a success in most logs.
-
Put recruiters in front of the pilot data
Have recruiters work their own pilot requisitions end to end. They immediately spot missing feedback, wrong stages and unreadable history that reconciliation cannot see.
-
Test migration on sandbox
both Bullhorn and Avionte offer sandbox/test environments. Run the full migration pipeline against test data first.
PII Masker Never load real customer PII into a sandbox
Bullhorn → Avionté specifics
- Light industrial and clerical focus
- Avionte was purpose-built for high-volume temp staffing verticals — clerical, light industrial, IT staffing. Agencies in these verticals often find Avionte's workflows more aligned with their day-to-day operations.
- Field-level spot check
- randomly sample 2% of records (minimum 100) per entity type. Compare every field value.
- Relationship integrity check
- for sampled records, verify that linked entities resolve correctly in Avionte.
- User Acceptance Testing (UAT)
- have 3–5 recruiters perform their normal workflows in Avionte using migrated data. Ask them to find specific candidates, verify placement histories, and check that notes appear correctly.
Don't move on until
- Candidate-application-job relationships intact for the pilot
- Funnel counts per stage match source for pilot jobs
- Resume files open correctly for every pilot candidate
05 Cutover Switch recruiting without dropping a live candidate.
Objective All in-scope recruiting data live in Avionté, careers site and boards repointed, recruiters working.
Keep these open
-
Pre-load historical candidates and closed jobs
Load closed requisitions, rejected candidates and archived applications while Bullhorn stays live. Only active pipeline and the final delta need to move in the window.
-
Publish the runbook including the careers-site switch
A timed sequence with owners and abort criteria, treating the careers site and job boards as first-class steps. They are candidate-facing, so a failure there is publicly visible in a way a data defect is not.
-
Freeze Bullhorn and take the final delta
Stop new applications and let recruiters finish in-flight actions, then export everything changed since the pre-load. Coordinate with anyone actively interviewing so feedback is not entered into the old system mid-freeze.
Interview feedback entered in the old ATS during the freeze is lost, and it is the data recruiters most immediately notice missing.
-
Load active pipeline and reconcile stages
Load active candidates and applications, then verify every active candidate is at the correct stage on the correct job before repointing anything. Active-stage accuracy is what recruiters check first on day one.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint careers site, job boards and integrations
Switch the careers-site integration, repost or migrate live job ads, and repoint HRIS, background check, assessment and calendar integrations. Then submit a real test application through the careers site and every major board.
Job ads left posted against the old ATS keep collecting applications that never reach the new system.
-
Go/no-go and switch recruiters over
Call the decision against the exit criteria, then move recruiters with support on hand for the first day. Keep Bullhorn read-only — candidate records have retention obligations that outlast the migration.
Bullhorn → Avionté specifics
- Rollback plan
- Avionte doesn't have a one-click rollback. Your rollback plan is your Bullhorn instance, which should remain active and unchanged until validation is complete. Do not decommission Bullhorn until UAT passes.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Avionté and verified
- Active candidates confirmed at the correct stage
06 Validation Prove the funnel, the files and the compliance position.
Objective Reconciled recruiting data, funnel parity with baseline, and a defensible compliance record.
Keep these open
-
Reconcile every object including files
Compare counts for candidates, applications, jobs, interviews, scorecards and files, with field-level spot checks on a sample. Count files separately — they are the object most likely to be quietly short.
Migration Validation Tool Reconcile Bullhorn and Avionté record-for-record -
Tie funnel and time-to-hire reporting to baseline
Rebuild funnel conversion, time-to-hire, source effectiveness and offer-acceptance reporting and compare to pre-migration figures. Variances trace back to stage mapping and to how application timestamps were handled.
Time-to-hire depends on stage-transition timestamps. If those were approximated, the metric will differ even with identical records.
-
Verify file integrity at scale
Sample-open resumes across the whole load and compare file sizes against source. Zero-byte and truncated files are common and never surface in an upload success count.
-
Confirm retention, consent and EEO configuration
Verify retention rules, consent state and EEO segregation are correctly configured in Avionté, and that excluded records genuinely did not migrate. File this as your compliance evidence.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test workflow, notifications and candidate-facing paths
Fire every stage automation, interview scheduling flow, rejection template and offer approval, and submit a live application through the careers site. Candidate-facing emails going out wrong is a brand problem, not just a bug.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, retain Bullhorn read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Record count reconciliation
automated comparison of source counts vs. target counts per entity type. Aim for 100% on core entities.
-
Rebuild automations
Bullhorn Automation workflows do not export. Recreate equivalent workflows in Avionte.
-
Monitor for data drift
if you ran a parallel period, verify that any records created in Bullhorn during migration were captured in the final sync.
Bullhorn → Avionté specifics
- Field-level sampling
- randomly select 50–100 records per entity type and compare field values.
- Relationship validation
- verify that Contact → Company, Talent → Placement, and Placement → Job links are intact.
- Attachment verification
- spot-check that resumes and documents are accessible in Avionte.
- Reconfigure integrations
- job board feeds, VMS connections, background check providers, and onboarding tools need to be reconnected to Avionte.
- User training
- Avionte BOLD has a different UI paradigm. Budget 1–2 weeks for recruiter training before cutting over.
Don't move on until
- Reconciliation complete across candidates, applications and files
- Funnel and time-to-hire reporting tie to baseline
- Retention and EEO configuration verified, acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Concept Bullhorn Entity
| Bullhorn field | Avionté field | Notes |
|---|---|---|
| Client company | ClientCorporation | Direct mapping; Bullhorn auto-creates an archived ClientContact when creating a ClientCorporation |
| Hiring manager | ClientContact | Contacts in Avionte are tied to Companies |
| Candidate/worker | Candidate | Avionte uses "Talent" for all candidate types |
| Job requisition | JobOrder | Map status values manually (e.g., "Accepting Candidates" → "Open") |
| Submission | JobSubmission | Avionte pipelines candidates to jobs differently |
| Placement | Placement | Back-office fields (pay rate, bill rate) map natively in integrated BOLD |
| Sales pipeline | Opportunity | Must flatten to notes or custom fields |
| Notes | Note | Bullhorn Notes reference Candidate, ClientContact, JobOrder, or Placement; Avionte activities live on the Talent record |
| Appointments | Appointment | Collapse into activity records |
| Custom objects | PersonCustomObjectInstance1–35 | Data must be serialized into custom fields or discarded |
| File attachments | CandidateFileAttachment | Avionte supports resume parsing on import; other file types need API-level handling |
Data Can It Migrate?
| Bullhorn field | Avionté field | Notes |
|---|---|---|
| Candidate/Talent core fields | ✅ | Direct mapping |
| Company and Contact records | ✅ | Direct mapping |
| Job Orders | ✅ | Status values need mapping |
| Placements | ✅ | Back-office fields map natively in integrated BOLD |
| Notes and Activities | ⚠️ | Requires API; loses multi-entity association (flattens to Talent) |
| Custom Objects | ❌ | Must serialize to custom fields or discard |
| Opportunities | ❌ | No Avionte equivalent |
| File Attachments | ⚠️ | API only; Bulk Import doesn't support |
| Automation rules & workflows | ❌ | Must be rebuilt in Avionte |
| Email history | ⚠️ | Partial; depends on what Bullhorn stored vs. email provider |
| Submission history | ⚠️ | Must be restructured into Avionte's pipeline model |
| Bullhorn Data Hub custom schemas | ❌ | No equivalent in Avionte |
Bullhorn Avionte BOLD
| Bullhorn field | Avionté field | Notes |
|---|---|---|
| id | N/A (internal) | Store in mapping table |
| firstName | FirstName | Direct |
| lastName | LastName | Direct |
| Direct; used for dedup | ||
| phone | Phone | Strip formatting |
| status | Status / StatusId | Picklist mapping required |
| address.address1 | Address1 | Flatten nested object |
| address.city | City | Direct |
| address.state | State | Direct |
| address.zip | Zip | Direct |
| customText1–customText20 | Custom fields (limited) | Map selectively |
| name | CompanyName | Direct |
| clientContacts | Contacts (linked) | Rebuild association via mapping table |
| title | JobTitle | Direct |
| startDate | StartDate | Date format conversion |
| clientCorporation.id | CompanyId | Resolve via mapping table |
| comments | ActivityNotes | Flatten; lose multi-entity linkage |
| dateAdded | ActivityDate | Preserve timestamp |
| payRate | PayRate | Direct |
| clientBillRate | BillRate | Direct |
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I export data from Bullhorn to Avionte using CSV?
Yes, but with major limitations. Bullhorn Automation exports cap at 50,000 records, and CSV flattens all relational data. Avionte's Bulk Import handles Jobs, Placements, and Companies but not notes, activities, or attachments. For anything beyond simple flat data, you need the API.
What is the Bullhorn API rate limit?
Bullhorn enforces a maximum of 1,500 API calls per minute per API user. Exceeding this returns a 429 Too Many Requests error. The BhRestToken also expires after approximately 10 minutes of idle time, requiring a refresh token flow.
Does Avionte BOLD support custom objects like Bullhorn?
No. Bullhorn supports up to 35 PersonCustomObjectInstances and 10 per JobOrder, Placement, and ClientCorporation. Avionte BOLD has no equivalent structure. Custom object data must be serialized into available custom fields or exported to a separate system.
How long does a Bullhorn to Avionte migration take?
For small agencies (under 10K records) using CSV, a few days. For enterprise datasets (50K+ records) using API-based migration with full relational preservation, expect 2–6 weeks including test migrations, validation, and UAT. The Bullhorn extraction phase alone can take 4+ hours for 100K candidates due to rate limits.
What data is lost when migrating from Bullhorn to Avionte?
Bullhorn Opportunities have no Avionte equivalent and cannot migrate directly. Custom object instances must be flattened or discarded. Automation workflows must be rebuilt. Notes lose their multi-entity associations (they flatten to Talent-level activities). Submission history must be restructured into Avionte's pipeline model.