Migrate from Sage HRMS to Bullhorn ATS & CRM

Sage HRMS Employee records map to Bullhorn Candidate records for firms recruiting for their own headcount. EmployeeID, name fields, address, contact info, date of hire, job title, and department assignment migrate as standard Candidate fields. Biographical data, employment status, and org assignment (Position, Pay Group) are mapped to typed Bullhorn Candidate fields or custom fields. Employee records from Sage HRMS that represent candidates for external placements (if the ATS module is active) map to Candidates with a source tag indicating the internal HRMS origin.

For staffing firms, Sage HRMS Employee records for internal staff (recruiters, account managers, operations) map to Bullhorn Contact records. The Contact represents the internal team member using Bullhorn, not a candidate or client. We map name, email, phone, and department to Bullhorn Contact fields and configure the appropriate user type during Bullhorn setup.

Sage HRMS Departments map to Bullhorn Client records. The department name becomes the Client name, cost center assignments become custom fields on the Client record, and the organizational hierarchy is preserved as a custom field tree or a Note attachment. If the organization has a multi-level department structure, we create a custom field department_level_1 through department_level_5 to represent the full hierarchy in Bullhorn.

Sage HRMS Positions define job titles, grade levels, and pay ranges. In Bullhorn, these map to Job Order templates rather than direct records. We extract the position table (title, description, grade, pay range low/high, FLSA status) and use it to pre-populate Bullhorn Job Order templates so that when a recruiter creates a new job order matching an internal position, the pay structure and classification are pre-loaded. FLSA status and exempt/non-exempt classification migrate as custom fields on the Job record.

Sage HRMS Pay Groups define pay frequency (weekly, biweekly, semimonthly, monthly), deduction priority order, and tax jurisdiction. Bullhorn has no native Pay Group concept. We extract Pay Group definitions and create Bullhorn custom fields on the Placement object: pay_frequency, deduction_priority, and tax_jurisdiction. The values populate when a Placement is created and carry the pay structure from Sage HRMS into Bullhorn's billing context.

Historical earnings, deductions, and tax withholdings from Sage HRMS do not have a native Bullhorn equivalent because Bullhorn manages placement billing (what the client pays the agency) rather than employee payroll. We extract the last two to three fiscal years of payroll history as a summary object: annual earnings bands, total tax withholdings, and year-end totals. These are stored as a document attachment (CSV export) on the corresponding Candidate record and as a structured custom fields set on the Placement for compliance and audit purposes.

Benefit enrollments, carrier assignments, and coverage tiers from Sage HRMS do not map to any standard Bullhorn object. We extract active benefit plan enrollments per employee and create a structured custom fields section on the Candidate record (benefit_plan_type, carrier_name, coverage_tier, enrollment_status). If the enrollment data is complex or includes multiple dependents, we deliver it as a CSV file attachment on the Candidate record keyed by EmployeeID.

Federal, state, and local tax codes from Sage HRMS define payroll tax jurisdictions and withholding rules. Bullhorn does not process payroll taxes. We extract the tax code table and create Bullhorn custom fields on Job and Placement records (federal_tax_code, state_tax_code, local_tax_code, eic_status) so that staffing firms can track tax jurisdiction requirements for compliance and billing purposes. The tax code values are reference data only in Bullhorn.

Sage HRMS stores employee documents (I-9s, W-4s, offer letters, performance reviews, benefit elections) as file attachments in the database. We extract these as a file bundle keyed by EmployeeID and load them into Bullhorn as file attachments on the corresponding Candidate record. Each document type is placed in a named subfolder (i9, w4, offer_letter, performance_review, benefit_election) within the candidate's document library. We verify that Bullhorn's file attachment limit is not exceeded for any single candidate during migration.

Accrual rules and current time-off balances from Sage HRMS have no Bullhorn equivalent in a recruiting context. We extract balances as of the migration date and store them as a structured Note on the Candidate record (accrual_type, balance_hours, accrued_date, policy_name). If the customer's Bullhorn instance has the Bullhorn Time and Expense module active, we map balances to the corresponding time-tracking records there.

Sage HRMS performance review templates, ratings, and narrative responses migrate to a Bullhorn Custom Object (PerformanceReview) linked to the Candidate record. The Custom Object captures review_date, rating_value, reviewer_name, and narrative_text fields. If the Sage HRMS schema uses a separate review table with multiple review cycles per employee, we create multiple Custom Object records per Candidate, ordered by review_date.

If the Sage HRMS ATS module is active, job requisitions, candidate profiles, and application status migrate to Bullhorn Job Order (requisition), Candidate (profile), and a custom Application status field on the Candidate record. We extract active and recent candidates from the ATS table, map their application status (new, screening, interview, offer, hired, rejected) to Bullhorn Candidate status values, and link them to the corresponding Job Order if a matching requisition exists.

Sage HRMS user accounts and role-based permissions map to Bullhorn User records. We extract user names, email addresses, and role assignments and provision corresponding Bullhorn Users with matching user types (Full Recruiter, Limited Recruiter, Standard, Read-Only, or Admin). Sage HRMS role permissions are documented in a written permissions matrix so the customer's Bullhorn admin can configure equivalent access controls post-migration.

Sage HRMS custom fields on Employees, Positions, Jobs, and other objects are inventoried during discovery and re-created as Bullhorn custom fields on the equivalent entity. We map field data types (text, number, date, picklist, checkbox) to the corresponding Bullhorn custom field type. ESS-specific custom columns from Sage HRMS that do not survive a version upgrade are flagged as requiring re-creation in Bullhorn as standard custom fields rather than custom component fields, per Bullhorn's guidance that custom component fields are reserved for integrations only.