HRMS migration
Field-level mapping, validation, and rollback between HR Manager Pro and Bullhorn ATS & CRM. We move data and schema; workflows are rebuilt natively in Bullhorn ATS & CRM.
HR Manager Pro
Source
Bullhorn ATS & CRM
Destination
Compatibility
8 of 12
objects map 1:1 between HR Manager Pro and Bullhorn ATS & CRM.
Complexity
BStandard
Timeline
1-2 weeks
Overview
HR Manager Pro is a WordPress plugin serving small businesses as an all-in-one HR and applicant tracking tool; Bullhorn is a cloud ATS and CRM purpose-built for staffing and recruitment agencies. The migration is an architectural shift from a flat, CSV-export-driven WordPress plugin to a relational API-driven recruitment platform with Candidate, ClientCorporation, Job, JobOrder, and Placement entities. We extract from HR Manager Pro via CSV (the plugin has no REST API), pre-create Bullhorn custom fields and custom objects to absorb non-standard HR Manager Pro properties, run document downloads from the WordPress media library in parallel, then write records into Bullhorn via the REST API with rate-limit handling. Bullhorn's custom object limits (2 on Bullhorn ATS, 10 on Front Office Growth/Enterprise per entity) constrain how many HR Manager Pro custom fields can land natively; we flag this during scoping and route overflow fields to a supplemental spreadsheet for admin entry. Workflows, leave accrual rules, and HR Manager Pro's leave management module do not migrate to equivalent Bullhorn features because Bullhorn's feature set is recruitment-focused, not general-HR.
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 HR Manager Pro 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.
HR Manager Pro
Candidate
Bullhorn ATS & CRM
Candidate
1:1HR Manager Pro candidate records (name, email, phone, resume, status, source, notes) map directly to Bullhorn Candidate. The HR Manager Pro status field (applied, interview, offer, hired, rejected) maps to Bullhorn Candidate.status with a custom status value set we configure before migration. Resume files are downloaded from the WordPress media library and uploaded to Bullhorn via the Candidate Document API endpoint, linked as ContentDocument with a DocumentType of Resume. Candidate source attribution migrates to a custom Candidate field candidateSource__c if the customer's Bullhorn edition limits the standard source picklist.
HR Manager Pro
Company
Bullhorn ATS & CRM
ClientCorporation
1:1HR Manager Pro Company records (company name, address, industry, website, primary contact) map to Bullhorn ClientCorporation. The primary contact person from HR Manager Pro maps to a Bullhorn Contact record linked to the ClientCorporation via the clientCorporationId lookup. If HR Manager Pro stores multiple contacts per company, each becomes a separate Bullhorn Contact under the same ClientCorporation. Company deduplication uses name and website as the key.
HR Manager Pro
Job Posting
Bullhorn ATS & CRM
Job
1:1HR Manager Pro job postings map to Bullhorn Job records. The HR Manager Pro job title maps to Job.title, description maps to Job.description (with HTML formatting preserved where present in the source). Employment type, location, and salary range from HR Manager Pro map to Bullhorn custom fields (jobType__c, address__c, salaryMin__c, salaryMax__c) because Bullhorn's standard Job object uses JobAddress for location and does not include a native salary range field.
HR Manager Pro
Application
Bullhorn ATS & CRM
JobSubmission
1:1HR Manager Pro applications (candidate applied to a specific job) map to Bullhorn JobSubmission. We resolve the CandidateId and JobId references at migration time using the email match on Candidate and the job title match on Job. Application status (pending, reviewed, shortlisted, interview_scheduled, offer_extended, placed, rejected) maps to a custom JobSubmission status field or the standard submissionStatus__c if the Bullhorn edition exposes it. A submitted candidate without a matching Job record is held in a pending queue for manual Job creation before the submission inserts.
HR Manager Pro
Employee
Bullhorn ATS & CRM
User or Contact
1:manyHR Manager Pro Employee records split into two Bullhorn targets. Internal staff who will use Bullhorn as system users (recruiters, sales staff, administrators) map to Bullhorn User records with email as the match key and a custom field originalEmployeeId__c for audit. Employee records representing the customer's own workforce (not candidates or client contacts) map to Bullhorn Contact records in a separate contact segment. Bullhorn Users require active Bullhorn seat licensing; we flag this during scoping and the customer provisions the required seats before User migration proceeds.
HR Manager Pro
Department
Bullhorn ATS & CRM
Corporate Department (custom object) or tag
lossyHR Manager Pro department taxonomy has no native Bullhorn equivalent. Bullhorn does not include a Company Department concept in standard objects. We offer two migration paths during scoping: (1) map departments to a Bullhorn custom object CorporateDepartment__c with a lookup from Contact or User, limited by the customer's custom object quota (2 on Bullhorn ATS, 10 on Enterprise); or (2) map departments as tags on Contact/User records using the Tag entity. The customer selects the approach before field map finalization.
HR Manager Pro
Leave Policy and Balance
Bullhorn ATS & CRM
Custom field snapshot (no accrual logic)
lossyHR Manager Pro leave entitlement and accrual balances migrate as static values only. Bullhorn has no absence management module, so there is no destination object to carry accrual rules, carryover limits, or vesting schedules. We write current leave balances as custom fields on the Contact or User record (e.g., annualLeaveRemaining__c, sickLeaveBalance__c) and advise the customer's admin to configure leave entitlements in a dedicated absence management system post-migration.
HR Manager Pro
Document (Employee)
Bullhorn ATS & CRM
ContentDocument
1:1Employee documents (contracts, certifications, government IDs) stored in the WordPress media library require a parallel download step. The HR Manager Pro CSV contains the file path or WordPress attachment ID; we download each file, map it to the target Bullhorn record (Candidate or Contact) by matching on the parent employee/candidate name, and upload via Bullhorn's ContentDocument REST API with a custom DocumentType classification. This step adds 15-30 minutes per 100 documents depending on file size and WordPress server response time.
HR Manager Pro
Custom Fields (Employee)
Bullhorn ATS & CRM
Custom fields on Candidate, Contact, or User
lossyHR Manager Pro allows admin-defined custom fields on employee profiles that are discovered only during pre-migration scan. We map each discovered custom field to a Bullhorn custom field on the relevant entity (Candidate for applicant-facing fields, Contact for workforce fields). Bullhorn's custom field limits apply: Bullhorn ATS is capped at 2 custom objects with 55 fields each; Front Office Growth/Enterprise allows 10 custom objects with 55 fields each. If the customer's HR Manager Pro schema exceeds the Bullhorn edition's quota, we route overflow fields to a supplemental CSV for manual admin entry and flag the constraint during scoping.
HR Manager Pro
Placement (if tracked)
Bullhorn ATS & CRM
Placement
1:1If HR Manager Pro tracks placements (hired candidates tied to a job), these map to Bullhorn Placement records. The Placement object links CandidateId, JobOrderId (derived from the mapped Job), ClientCorporationId, and custom billing fields (payRate__c, billRate__c, overtimeRate__c). Placement date, termination date, and status migrate as Placement.dateBegin, dateEnd, and a status picklist configured during schema setup.
HR Manager Pro
Engagement: Note
Bullhorn ATS & CRM
Note
1:1HR Manager Pro notes attached to candidate or employee records map to Bullhorn Note records linked via ContentDocumentLink to the parent Candidate, Contact, or ClientCorporation. Note body migrates as plain text. The original note author and timestamp migrate to Note.createdById and Note.createdDate for audit trail integrity.
HR Manager Pro
Engagement: Call / Meeting
Bullhorn ATS & CRM
Task (TaskSubtype = Call or Event)
1:1HR Manager Pro call and meeting logs attached to candidate records map to Bullhorn Task with TaskSubtype = Call (for calls) or Event (for meetings). Call duration, disposition, and outcome migrate to custom Task fields (callDuration__c, callDisposition__c). Meeting location, start time, and end time migrate to Bullhorn Event fields. Attendee associations in HR Manager Pro map to EventRelation records pointing to the relevant Candidate or Contact.
| HR Manager Pro | Bullhorn ATS & CRM | Compatibility | |
|---|---|---|---|
| Candidate | Candidate1:1 | Fully supported | |
| Company | ClientCorporation1:1 | Fully supported | |
| Job Posting | Job1:1 | Fully supported | |
| Application | JobSubmission1:1 | Fully supported | |
| Employee | User or Contact1:many | Fully supported | |
| Department | Corporate Department (custom object) or taglossy | Fully supported | |
| Leave Policy and Balance | Custom field snapshot (no accrual logic)lossy | Fully supported | |
| Document (Employee) | ContentDocument1:1 | Fully supported | |
| Custom Fields (Employee) | Custom fields on Candidate, Contact, or Userlossy | Fully supported | |
| Placement (if tracked) | Placement1:1 | Fully supported | |
| Engagement: Note | Note1:1 | Fully supported | |
| Engagement: Call / Meeting | Task (TaskSubtype = Call or Event)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.
HR Manager Pro gotchas
No API forces reliance on CSV export scoping
Leave balance accrual logic does not export
File attachments require separate download workflow
Custom fields discovered only at scan time
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 CSV scoping
We run a pre-migration scan against the live WordPress instance to enumerate HR Manager Pro employee and candidate profiles, custom field schemas, department taxonomy, document attachment count, and leave balance records. We export the full HR Manager Pro CSV (employees, candidates, companies, job postings, applications) and review the column headers against Bullhorn's required and available fields. The discovery output is a written migration scope document that specifies the object-level mapping, custom field inventory, document count estimate, and any gaps (missing required Bullhorn fields, fields exceeding custom object quota) requiring customer action before migration day.
Bullhorn schema pre-creation and custom field setup
We configure the Bullhorn destination schema before any data migrates. This includes creating any custom Candidate, Contact, Job, JobSubmission, or Placement fields required to absorb HR Manager Pro custom properties. We also create the CorporateDepartment custom object (or configure the tag-based fallback) if department mapping is in scope, and we configure the Candidate status value set to match the customer's HR Manager Pro status pipeline. Bullhorn custom objects and fields are deployed to a Sandbox org first for validation before production deployment.
Document download from WordPress media library
We run the parallel document download step against the WordPress media library while the Bullhorn schema is being validated. We extract each document's binary from the WordPress uploads directory using the attachment IDs from the CSV, validate the file type and size, and store them in a staging area keyed by candidate or employee record. The document download step runs independently and does not block schema configuration, but must complete before the final Bullhorn document upload phase begins.
Sandbox migration and reconciliation
We execute a full migration into a Bullhorn Sandbox using production-like data volume from the scoping export. The customer's Bullhorn admin reconciles record counts (Candidates in, ClientCorporations in, Jobs in, JobSubmissions in, Documents in), spot-checks 25-50 random candidate records against the HR Manager Pro source, and validates that custom field values populated correctly. Any mapping corrections (wrong field type, field length exceeded, required field missing) happen in this phase. The customer signs off on the sandbox reconciliation before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: ClientCorporations (from HR Manager Pro Company records), Candidates (with document upload to ContentDocument linked by CandidateId), Jobs (with custom salary and employment type fields), JobSubmissions (with CandidateId and JobOrderId resolved), Placements (with all parent references resolved), Contacts or Users (for internal employee records), and leave balance snapshots (as custom fields on Contact/User). Each phase emits a row-count reconciliation report before the next phase begins. Bullhorn API rate limits are handled with exponential backoff and batch chunking to avoid throttling on large candidate imports.
Cutover, final validation, and inventory handoff
We freeze HR Manager Pro writes during cutover, run a delta migration of any records modified during the migration window, then enable Bullhorn as the system of record. We deliver a written migration inventory covering migrated record counts, document upload summary, unmigrated data (leave accrual rules, workflow configurations), and supplemental CSV files for manual admin entry of overflow custom fields. We support a one-week hypercare window to resolve any reconciliation issues raised by the customer's team.
Platform deep dives
HR Manager Pro
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 HR Manager Pro 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
HR Manager Pro: Not applicable.
Data volume sensitivity
HR Manager Pro 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 HR Manager Pro to Bullhorn ATS & CRM migration scoping. Not seeing yours? Book a call.
Walk through your HR Manager Pro 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 HR Manager Pro
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.