HRMS migration
Field-level mapping, validation, and rollback between CATS and Bullhorn ATS & CRM. We move data and schema; workflows are rebuilt natively in Bullhorn ATS & CRM.
CATS
Source
Bullhorn ATS & CRM
Destination
Compatibility
8 of 12
objects map 1:1 between CATS and Bullhorn ATS & CRM.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from CATS to Bullhorn is a migration from a lightweight, per-seat-priced ATS to an industry-specific ATS and CRM built for staffing firms. CATS exports Candidates and Job Orders as XLS or CSV batches with no documented public REST API for bulk pull, so we automate the export trigger and feed the generated file into our Bullhorn import pipeline. Custom fields in CATS — a common configuration for tracking sourcing channels, clearance levels, or pay-rate ranges — require Bullhorn Support to provision Custom Objects before migration, with a field-limit of 55 fields per Custom Object and edition-dependent caps on how many Custom Objects are available per entity. Pipeline stages in CATS map to Bullhorn Candidate Record Types and status values, which we configure before data moves. Workflows, email triggers, and routing rules in CATS are application configuration, not data, and do not transfer; we document every active workflow for the customer's Bullhorn admin to rebuild in Bullhorn's workflow engine post-migration. Owner assignments migrate by email match to Bullhorn User records, with a reconciliation queue for any CATS user lacking a Bullhorn seat.
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 CATS 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.
CATS
Candidate
Bullhorn ATS & CRM
Candidate
1:1CATS Candidates map directly to Bullhorn Candidate records. We extract all standard fields (firstName, lastName, email, phone, address, status, source) plus any CATS custom field values. CATS candidate status values (Active, On Hold, Dead) map to Bullhorn Candidate status using a mapping table defined during scoping. Candidate source attribution (LinkedIn, Referral, Job Board) migrates to the Bullhorn candidateSource field. Bullhorn requires a valid Candidate record before any linked activities can be imported, so Candidate import runs first in all phases.
CATS
Job Order
Bullhorn ATS & CRM
JobOrder
1:1CATS Job Orders map to Bullhorn JobOrder records. The CATS Job Order title, description, status, department, and internal ID migrate to Bullhorn JobOrder title, description, status, and externalID. CATS pipeline stage assignments map to Bullhorn JobOrder Record Type and status values; we configure these as Bullhorn Record Types during the pre-migration phase. JobOrders without an assigned recruiter in CATS receive a default Bullhorn Owner resolved from the user mapping.
CATS
Activity
Bullhorn ATS & CRM
Task and Event
1:1CATS Activities (calls, emails, notes, interviews) linked to candidates and job orders migrate to Bullhorn Task and Event records. Call activities map to Task with TaskSubtype=Call and CallDurationInSeconds preserved. Email activities map to Task with Subject, Body, and direction (inbound/outbound) preserved. Meeting activities map to Bullhorn Event with StartDateTime, EndDateTime, and Location. Notes map to Task with IsTask=false. All activities retain the original CATS timestamp for timeline ordering and link to the Candidate or JobOrder via the Bullhorn targetEntityID and targetEntityType fields.
CATS
Custom Field
Bullhorn ATS & CRM
Custom Object
lossyCATS custom fields on Candidates and Job Orders require Bullhorn Custom Object configuration before migration. Bullhorn Support must create each Custom Object via a spreadsheet submission (one per entity type, up to 10 on Front Office Growth/Enterprise, 2 on Bullhorn ATS, 0 on ATS Growth). We scope all CATS custom field names, types (text, dropdown, date, checkbox), and values during discovery, then coordinate with Bullhorn Support to provision the equivalent Custom Objects. Each Custom Object supports up to 55 fields, split across edit types (checkboxes, dropdowns, pickers, and free text). Custom field values migrate as Custom Object instance records linked to the parent Candidate or JobOrder.
CATS
User
Bullhorn ATS & CRM
User
1:1CATS user accounts (name, email, role, department) map to Bullhorn User records by email match. We extract the full CATS user roster and resolve each email address against the Bullhorn User table. Any CATS user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import. OwnerId references on Candidate, JobOrder, and Activity records are resolved at migration time from this user mapping. Reducing CATS seats post-migration requires separate account management steps outside migration scope.
CATS
Pipeline Stage
Bullhorn ATS & CRM
Record Type + Status
lossyCATS pipeline stages (New, Screening, Interview, Offer, Hired, Rejected) map to Bullhorn Candidate Record Types and Candidate status values. We extract the current CATS pipeline configuration during discovery and create corresponding Bullhorn Record Types (e.g., Direct-Hire Pipeline, Contract Pipeline) with status picklists that whitelist the mapped stage names. Stage ordering and probability percentages migrate to Bullhorn Candidate status configurations. If the CATS instance has multiple pipelines, each becomes a separate Bullhorn Record Type.
CATS
Tag
Bullhorn ATS & CRM
Candidate Tags
lossyCATS tags (free-text or pre-defined) on candidates migrate to Bullhorn Candidate Tags. Tags are stored as comma-separated values in CATS and split into individual Bullhorn Tag records linked to the Candidate. If the customer's Bullhorn edition limits tag functionality, we map tags to a multi-select custom text field on the Candidate Custom Object as a fallback. The customer chooses the strategy during scoping.
CATS
Source
Bullhorn ATS & CRM
candidateSource
1:1Candidate source values in CATS (LinkedIn, Referral, Job Board, Indeed, etc.) migrate to Bullhorn Candidate.candidateSource. If the destination Bullhorn instance uses a restricted picklist for candidateSource, we map CATS values to the nearest matching Bullhorn value and flag any unmapped sources for the customer's admin to add to the picklist.
CATS
Attachment
Bullhorn ATS & CRM
ContentDocument + ContentDocumentLink
1:1CATS file attachments (resumes, cover letters, portfolios) linked to candidates migrate as Bullhorn ContentDocument records with ContentDocumentLink associations to the Candidate. We pull attachments via the CATS export tool or API, preserve original file names and MIME types, and upload them to Bullhorn's document storage. The ContentDocumentLink links the file to the Candidate (or JobOrder) record with ShareType='V' (viewer access). Bullhorn's storage limits depend on the edition; we flag any customer approaching storage thresholds before migration.
CATS
Department
Bullhorn ATS & CRM
Company or custom field
lossyCATS departments categorize job orders and sometimes users. We export the department list and recreate it in Bullhorn as either Bullhorn Company records (if the department represents a client organization) or as a custom text field on JobOrder (if it represents an internal division). The customer chooses the strategy during scoping. Department-user assignments migrate as part of the user mapping if the department structure maps to Bullhorn organizational roles.
CATS
Workflow
Bullhorn ATS & CRM
Not migrated
1:1CATS workflows govern record routing, email triggers, and status-change automation. Workflows are application configuration, not data, and cannot be exported from CATS. We document every active CATS workflow during discovery (trigger conditions, actions, recipients) and deliver a written workflow-mapping deliverable that maps each CATS workflow to a recommended Bullhorn workflow equivalent (Bullhorn's native workflow engine, email automation rules, or Bullhorn Marketplace automation tools). The customer's Bullhorn admin rebuilds the rules post-migration.
CATS
Statistic / Report
Bullhorn ATS & CRM
Not migrated
1:1CATS reporting data (time-to-fill, source effectiveness, pipeline metrics) is derived from transactional records and not stored as a standalone data object. We do not migrate reporting snapshots. The customer's Bullhorn admin configures equivalent reports in Bullhorn using the migrated transactional data as the source. Bullhorn Enterprise includes advanced reporting dashboards; Bullhorn Team and Corporate include standard reporting. We provide a report-mapping deliverable listing the CATS reports in use and their Bullhorn equivalents.
| CATS | Bullhorn ATS & CRM | Compatibility | |
|---|---|---|---|
| Candidate | Candidate1:1 | Fully supported | |
| Job Order | JobOrder1:1 | Fully supported | |
| Activity | Task and Event1:1 | Fully supported | |
| Custom Field | Custom Objectlossy | Fully supported | |
| User | User1:1 | Fully supported | |
| Pipeline Stage | Record Type + Statuslossy | Fully supported | |
| Tag | Candidate Tagslossy | Fully supported | |
| Source | candidateSource1:1 | Fully supported | |
| Attachment | ContentDocument + ContentDocumentLink1:1 | Fully supported | |
| Department | Company or custom fieldlossy | Fully supported | |
| Workflow | Not migrated1:1 | Fully supported | |
| Statistic / Report | Not migrated1: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.
CATS gotchas
CATS exports are batch-based, not real-time API
Workflow automation does not transfer between systems
Per-seat licensing means imported candidates add no cost, but active users do
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 edition verification
We audit the source CATS instance for candidate volume, job order count, custom field definitions (name, type, entity), active workflow rules, department structure, user roster, and attachment volume. We pair this with a Bullhorn edition verification: Bullhorn Team ($99/user) covers basic ATS and CRM; Bullhorn Corporate ($199/user) adds unlimited data storage, API access, and custom fields; Bullhorn Enterprise adds advanced reporting, relationship intelligence, and full customization. We confirm the Custom Object limit for the customer's Bullhorn edition with their account manager and flag any CATS custom fields that exceed the limit. The discovery output is a written migration scope with record counts, custom field inventory, and Bullhorn edition recommendation.
Bullhorn Custom Object coordination and schema creation
We submit the Bullhorn Custom Object Setup spreadsheet to Bullhorn Support for each CATS custom field group that maps to a Bullhorn entity. Bullhorn Support configures the Custom Object schema (name, fields, edit types, department-level security) within their SLA. We monitor the Support ticket, validate the created Custom Object metadata via the Bullhorn REST API /meta endpoint, and confirm field names and types match the CATS source fields before any data migration begins. This step runs in parallel with data extraction from CATS and typically takes one to two weeks depending on Bullhorn Support response time.
CATS data extraction and transformation
We automate the CATS batch export for Candidates and Job Orders (XLS/CSV), extract Activities (calls, emails, notes, interviews) with timestamps and owner attribution, pull the user roster and department list, and bundle attachments for re-upload. The transformation layer maps CATS field names to Bullhorn field names, transforms CATS status values to Bullhorn Candidate status and JobOrder status, splits CATS custom field values into Custom Object instance records, and converts CATS pipeline stage names to Bullhorn Record Type and status values. We run a transformation dry-run and deliver a sample of 50 records for the customer's review before the full migration.
Sandbox migration and reconciliation
We run a full migration into a Bullhorn Sandbox environment (Full Copy if available) using production-like data volume. The customer's Bullhorn admin and recruiting lead reconcile record counts (Candidates in, JobOrders in, Activities in), spot-check 30-50 random records against the CATS source, and verify that custom field values landed correctly in the Bullhorn Custom Objects. Pipeline stage mapping and Record Type assignments are validated here. Any mapping corrections happen in the sandbox, not in production. The customer signs off the sandbox migration before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Custom Objects schema (validated), then Candidates (first, because activities and custom object instances link to them), then JobOrders (with Recruiter and Department resolved), then Users (if any new Bullhorn seats were provisioned during reconciliation), then Activities (Tasks, Events, Notes via Bullhorn REST API with rate-limit handling and exponential backoff), then Attachments (ContentDocument and ContentDocumentLink), then Custom Object instances (linked to the parent Candidate or JobOrder), then Tags (Candidate Tags or custom field). Each phase emits a row-count reconciliation report. We pause between phases to allow the customer to spot-check migrated data in Bullhorn.
Cutover, validation, and workflow rebuild handoff
We freeze CATS writes during cutover, run a final delta migration of any records modified during the migration window, then mark Bullhorn as the system of record. We deliver the CATS workflow inventory and workflow-mapping deliverable to the customer's Bullhorn admin. We support a one-week hypercare window where we resolve any reconciliation issues raised by the recruiting team. We do not rebuild CATS workflows as Bullhorn workflows inside the migration scope; that is a separate engagement or an internal admin task. Bullhorn Support or a Bullhorn implementation partner can assist with workflow rebuild if the customer requires additional assistance.
Platform deep dives
CATS
Source
Strengths
Weaknesses
Bullhorn ATS & CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across CATS and Bullhorn ATS & CRM.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
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
CATS: Not publicly documented.
Data volume sensitivity
CATS doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 CATS to Bullhorn ATS & CRM migration scoping. Not seeing yours? Book a call.
Walk through your CATS 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 CATS
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.