HRMS migration
Field-level mapping, validation, and rollback between isolved and Bullhorn ATS & CRM. We move data and schema; workflows are rebuilt natively in Bullhorn ATS & CRM.
isolved
Source
Bullhorn ATS & CRM
Destination
Compatibility
8 of 12
objects map 1:1 between isolved and Bullhorn ATS & CRM.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from isolved People Cloud to Bullhorn is a cross-domain migration: isolved organizes data around full HCM records (employee, payroll, benefits, time-off, direct deposit, and defined picklists for job codes, work locations, and pay types), while Bullhorn is a recruiting ATS/CRM whose core entity model centers on Candidate, Contact, Company, Job, and Placement. We do not treat Bullhorn as an HRMS replacement — we migrate what Bullhorn natively supports (candidates, contacts, companies, jobs, placements, notes, and custom objects) and we deliver a written data catalog for the benefit enrollments, payroll history, and time-off balances that require a complementary HRMS or manual re-entry in Bullhorn's back-office context. Defined picklists (Job Codes, Work Locations, Pay Types, Workers Comp Codes) from isolved must be manually mapped to Bullhorn's corresponding picklists or stored as custom fields because neither platform exposes a universal cross-walk. Bullhorn's Custom Object framework (available on Front Office Growth and Enterprise tiers, up to 10 custom objects with 55 fields each) is the primary vehicle for carrying isolved custom fields that have no native Bullhorn equivalent. We export isolved data via its batch file format, encrypt SSN and banking fields in transit, and import through Bullhorn's REST API with rate-limit handling and chunking.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a isolved object lands in Bullhorn ATS & CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
isolved
Employee
Bullhorn ATS & CRM
Candidate or Contact
1:manyisolved Employee is the core HCM record with SSN, DOB, hire date, employment category, and compensation. We split at migration time: active candidates for open requisitions map to Bullhorn Candidate; current and historical employee records that represent placed workers map to Bullhorn Candidate with a Placement record; records with no recruiting context (pure payroll-only employees) do not have a native Bullhorn equivalent and are flagged for the customer's admin to determine whether to enter manually or store in a custom object. The Candidate custom1-candidate custom50 fields carry the migrated employee identifier for cross-reference.
isolved
Employee
Bullhorn ATS & CRM
Contact
1:1isolved Employee records with company affiliation map to Bullhorn Contact under the corresponding Company (Client Corporation) record. The mapping uses the employee's work email as the dedupe key. Marital status, citizenship, and ethnicity fields that have no native Bullhorn Contact field are stored in Bullhorn Custom Objects attached to the Contact.
isolved
Company (Employer)
Bullhorn ATS & CRM
Client Corporation
1:1isolved's employer-level Company record (the customer's own organization) maps to Bullhorn Client Corporation only if the isolved instance tracks client companies as a separate entity. Most isolved HCM deployments use Employee as the primary record; in those cases we create a single Client Corporation representing the employer and link all Candidate records to it.
isolved
Job Code
Bullhorn ATS & CRM
Custom Object or Custom Field
lossyisolved Job Codes are employer-defined picklist values used for classification, compensation rules, and compliance. Bullhorn has no native Job Code field on Candidate or Job. We export the full isolved Job Code picklist table and create a Bullhorn Custom Object (max 55 fields per object) to hold Job Code definitions, then add a lookup Custom Field on Candidate and Job referencing that object. The customer's Bullhorn admin adds the picklist values through Bullhorn Support.
isolved
Work Location
Bullhorn ATS & CRM
Custom Object + Candidate Field
lossyisolved Work Locations drive tax withholding, workers comp codes, and benefit eligibility across geographic or legal work sites. Bullhorn's Job record includes a City and State field but no Work Location concept. We create a Bullhorn Custom Object to store Work Location definitions (address, tax jurisdiction, workers comp code) and add a Custom Field on Candidate and Job referencing it. Multi-state compliance data from isolved is preserved as structured text in the Custom Object.
isolved
Pay Group
Bullhorn ATS & CRM
Custom Object
lossyisolved Pay Groups control pay frequency (weekly, biweekly, semi-monthly, monthly) and overtime rules per group. Bullhorn has no native Pay Group entity. We create a Bullhorn Custom Object with fields for frequency, overtime rule, and effective date, linked to Placement records where applicable. Pay Group definitions that drive billing rates in staffing contexts map to the Placement's bill rate fields.
isolved
Payroll History
Bullhorn ATS & CRM
Custom Object (Historical Payroll)
1:1Historical payroll registers including earnings, deductions, taxes, and garnishment orders migrate to Bullhorn Custom Object records attached to the corresponding Candidate or Contact. We extract full payroll history from isolved as structured line items grouped by pay period, remap deduction codes using the isolved-to-Bullhorn deduction code matrix, and preserve amounts and pay-period dates. Garnishment orders are stored as structured records in a separate Custom Object with fields for order amount, deduction code, and jurisdiction.
isolved
Benefit Enrollment
Bullhorn ATS & CRM
Custom Object (Benefit Elections)
1:1Active benefit elections (medical, dental, vision, HSA, FSA, life insurance) migrate to Bullhorn Custom Object records attached to the Candidate or Contact. isolved's plan and rate structure maps to custom fields for plan type, carrier, coverage level, and contribution amounts. Bullhorn does not have a native benefits administration module; the Custom Object approach preserves the election history for reference and audit but does not replace a dedicated benefits administration platform.
isolved
Time Off Balance
Bullhorn ATS & CRM
Custom Object (Accrued Time)
1:1Accrued and taken time off by type (PTO, sick, etc.) with carry-forward amounts migrates to Bullhorn Custom Object records. isolved calculates accruals per Work Location and Pay Group rules; we preserve the current balance, accrual rate, and accrual effective date. Bullhorn has no native time-off tracking; this Custom Object serves as a historical record only and cannot drive automated accrual recalculation.
isolved
Direct Deposit Account
Bullhorn ATS & CRM
Custom Object (Banking Reference)
1:1Employee banking information for payroll disbursement migrates to Bullhorn Custom Object records under encryption. We extract account routing number and account number fields, mask them in transit using field-level encryption, and store the masked reference with the Candidate. Bullhorn has no native direct deposit management; the Custom Object preserves the banking reference for customers who continue processing payroll in isolved or a separate payroll platform.
isolved
Workflow Transaction
Bullhorn ATS & CRM
Note or Task
1:1Pending or in-flight change requests (salary change, direct deposit update, name/contact change, HSA election) are stateful records in isolved that do not auto-close on import. We migrate open Workflow Transactions as Bullhorn Note records attached to the Candidate or Contact, with the transaction type and request date preserved in the Note body. Closed transactions are logged as completed Notes for audit trail purposes.
isolved
Document
Bullhorn ATS & CRM
ContentDocument (File)
1:1Electronically stored employee file attachments (offer letters, I-9s, performance reviews) migrate as Bullhorn ContentDocument records linked via ContentDocumentLink to the corresponding Candidate or Contact. We export document blobs with metadata from isolved and import to Bullhorn using the File (ContentVersion) API. We cannot guarantee document rendering fidelity for non-standard file types; the customer reviews documents post-migration in Bullhorn's document viewer.
| isolved | Bullhorn ATS & CRM | Compatibility | |
|---|---|---|---|
| Employee | Candidate or Contact1:many | Fully supported | |
| Employee | Contact1:1 | Fully supported | |
| Company (Employer) | Client Corporation1:1 | Fully supported | |
| Job Code | Custom Object or Custom Fieldlossy | Fully supported | |
| Work Location | Custom Object + Candidate Fieldlossy | Fully supported | |
| Pay Group | Custom Objectlossy | Fully supported | |
| Payroll History | Custom Object (Historical Payroll)1:1 | Mapping required | |
| Benefit Enrollment | Custom Object (Benefit Elections)1:1 | Fully supported | |
| Time Off Balance | Custom Object (Accrued Time)1:1 | Fully supported | |
| Direct Deposit Account | Custom Object (Banking Reference)1:1 | Fully supported | |
| Workflow Transaction | Note or Task1:1 | Fully supported | |
| Document | ContentDocument (File)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
isolved gotchas
PEPM billing model inflates post-migration costs silently
Payroll tax and deduction history requires SSAE-18 audit trail handling
Proprietary API with no publicly documented endpoint reference
Custom defined lists (Job Codes, Work Locations, Pay Types) must be exported and remapped
Implementation fee of 10–25% of annual contract plus contract lock-in
Bullhorn ATS & CRM gotchas
ATS Growth edition has no API access
Attachments excluded from CSV bulk exports
Custom Object limits vary sharply by edition
Opportunity pipeline stages are recruitment-specific
Resume parse quality varies by document format
Pair-specific challenges
Migration approach
Discovery and Bullhorn edition verification
We audit the isolved People Cloud instance for record count (active/inactive employees, payroll history volume, defined picklist size, open Workflow Transactions, document blob count), API export capability via partner integrations, and the customer's Bullhorn edition and Custom Object allocation. Bullhorn edition verification (ATS, ATS Growth, Front Office Growth, Enterprise) is critical because Custom Object capacity is gated by tier. The discovery output is a written migration scope document and a Bullhorn edition recommendation if the customer's current tier constrains the data model.
Custom Object schema design and Bullhorn Support coordination
We design the Bullhorn Custom Object schema to carry isolved benefit enrollments, payroll history, time-off balances, and defined-list reference data. Each Custom Object is defined with a Custom Object Setup Sheet submitted to Bullhorn Support (required for Bullhorn ATS editions). We map isolved deduction codes to Bullhorn Custom Object fields, define the Workers Comp Code reference structure, and configure Custom Fields on Candidate and Job to reference the Custom Objects. Schema design happens in parallel with the defined-list mapping matrix.
Defined-list export and mapping matrix
We export the full isolved picklist tables for Job Codes, Work Locations, Pay Types, and Workers Comp Codes. For each picklist value we identify the corresponding Bullhorn field or Custom Object entry. The mapping matrix is reviewed with the customer's Bullhorn admin; values not found in Bullhorn are flagged for manual addition via Bullhorn Support. The matrix is locked before record import begins so that no record lands with a null or mismatched classification code.
Sandbox migration and reconciliation
We run a full migration into a Bullhorn Sandbox (or a subset of production data in a test company) using production-like record volumes. The customer's Bullhorn admin reconciles record counts (Candidates in, Contacts in, Custom Object records in), spot-checks 25-50 records against the isolved source, and validates that picklist values resolved correctly. Mapping corrections and Custom Object field adjustments happen in the sandbox before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Client Corporation (employer record), then Candidate records (from isolved Employees with recruiting context), then Contact records, then Custom Objects for benefit enrollments and payroll history (with deduction code remapping applied), then time-off balances, then Workflow Transaction notes, then Documents. Each phase emits a row-count reconciliation report before the next phase begins. SSN and banking fields are encrypted in transit and stored masked in Bullhorn Custom Fields.
Cutover, validation, and document handoff
We freeze isolved writes during cutover and run a final delta migration of any records modified during the migration window. Bullhorn becomes the system of record for candidate and placement data. We deliver the defined-list mapping matrix, the Custom Object field catalog, and the deduction code cross-reference to the customer's Bullhorn admin. We support a one-week hypercare window for reconciliation issues. We do not rebuild isolved Workflow rules, benefits administration processes, or accrual calculation logic in Bullhorn; those are documented separately for the customer's HR admin to configure in a complementary HRMS.
Platform deep dives
isolved
Source
Strengths
Weaknesses
Bullhorn ATS & CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. All 7 core objects map 1:1 between isolved and Bullhorn ATS & CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across isolved and Bullhorn ATS & CRM.
Object compatibility
All 7 core objects map 1:1 between isolved and Bullhorn ATS & CRM.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
isolved: Not publicly documented.
Data volume sensitivity
isolved exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during isolved to Bullhorn ATS & CRM migration scoping. Not seeing yours? Book a call.
Walk through your isolved to Bullhorn ATS & CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave isolved
Other ways to arrive at Bullhorn ATS & CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.