Migrate from greytHR to Bullhorn ATS & CRM

greytHR Employee records split across two Bullhorn entities based on role context. Internal employees (HR, finance, operations staff) map to Bullhorn ClientContact attached to a ClientCorporation record representing the company. Candidates from greytHR's own hiring pipeline map to Bullhorn Candidate records. We preserve greytHR demographic fields (name, DOB, gender, mobile, email, address), employment fields (department, designation, grade, date of joining, employment type), and statutory fields (UAN, PAN, PF number, ESI number, TDS section) as Bullhorn standard or custom fields. The split is determined during scoping: if the customer was using greytHR to track job applicants, those records become Candidates; administrative staff become ClientContacts.

greytHR's structured statutory fields (UAN, PF account number, ESI number, PAN, TDS deduction section) have no native Bullhorn equivalent because Bullhorn is not an Indian payroll platform. We map each statutory field to a Bullhorn Custom Field on the Candidate and ClientContact entities. Bullhorn's Growth and Enterprise editions support up to 10 Custom Objects per entity with 55 fields each; we use standard custom fields first and reserve Custom Objects for compound or multi-value statutory data. These custom fields must be configured by Bullhorn Support or an admin with field mapping access before migration begins. We recommend downloading official PF and ESI slips from the greytHR government portal as a supplementary offline record.

greytHR stores leave entitlements, accrual history, current balances, carry-forward amounts, and encashment records per employee. Bullhorn has no native leave management module. We map current leave balances at migration cutoff to a Bullhorn Custom Object (customObject1s: Leave Balance) with fields for leave type, balance, accrual date, carry-forward, and encashment amount. The leave carry-forward logic, accrual rate, and policy-level rules do not migrate as data because greytHR applies them as policy definitions rather than stored formulas. We document the current leave policy settings during scoping so the customer's Bullhorn admin can configure equivalent rules manually or via Bullhorn Onboarding (formerly Able). In-progress accrual cycles are migrated as balance snapshots with a flag indicating the cycle was mid-run at cutover.

greytHR stores raw swipe logs with timestamps, shift schedule assignments, overtime entries, and regularization status per employee. Bullhorn does not have an attendance data model. We map swipe logs to a Bullhorn Custom Object (customObject2s: Attendance Record) with fields for employee reference (linked to ClientContact), date, in-time, out-time, shift, overtime hours, and regularization status. Note that greytHR attendance records with regularization requirements may reflect swipe visibility issues reported in greytHR reviews; we export both the raw swipe log and the regularization status and flag records where the two contradict, so the customer's admin can verify attendance before the migration cutoff.

greytHR payroll runs produce payslip records with gross salary, component-wise deductions (PF employee share, ESI employee share, TDS, professional tax), employer contributions (PF employer, ESI employer), and net pay. Bullhorn has no native payroll engine; the Bullhorn Time & Expense module and Bullhorn Onboarding handle timesheet-based billing for placed contractors, not payroll computation. We map greytHR payslip rows to a Bullhorn Custom Object (customObject3s: Payslip Record) linked to the ClientContact employee record. The salary computation rules (grade-based salary structures, deduction formulas, variable pay rules) are greytHR policy logic and do not export; we document the current salary structure and deduction setup for the customer to re-enter in their chosen payroll platform. We recommend a supplemental manual export of payroll reports from the greytHR UI for audit trail completeness.

greytHR tracks department transfers, designation changes, grade promotions, and location reassignments with effective dates as a position history timeline. Bullhorn's ClientContact model stores the current position and does not natively maintain a historical timeline. We map the most recent position assignment as the live ClientContact fields (title, business sector, department custom field) and preserve the full effective-dated history as a custom text field or a related Custom Object, depending on the volume of position changes. If the customer requires a clean position timeline for compliance or audit purposes, we document the complete history separately for manual entry or BI reporting.

greytHR stores expense claims with category, amount, approval status, reimbursement date, and linked employee. Bullhorn has no native expense claim module for internal employees. We map approved and pending expense claims to a Bullhorn Custom Object (customObject4s: Expense Claim) linked to the ClientContact employee. Claim status (approved, rejected, pending) and reimbursement details transfer. Custom expense categories defined in greytHR map to a Bullhorn custom picklist field on the Expense Claim custom object; if the destination Bullhorn edition does not support enough custom fields, we prioritize the most-used categories and document the remainder for manual categorization post-migration.

greytHR stores employee documents (offer letters, ID proofs, contracts, joining letters, promotion letters) in its document module. Bullhorn's ContentDocument and ContentVersion model handles document attachments on any entity. We export document metadata (filename, document type, upload date, related employee) from greytHR and link binary files to the corresponding Bullhorn Candidate or ClientContact record via ContentDocumentLink. Bullhorn's storage limits vary by edition; we flag total document volume during scoping to confirm the destination org has sufficient capacity. Some greytHR document access requires admin API credentials beyond standard user tokens; we request elevated read access during discovery.

greytHR PMS stores review cycles, rating scores, goals, and free-text feedback per employee. Bullhorn has no native performance management module. We map completed review records to a Bullhorn Custom Object (customObject5s: Performance Review) linked to the ClientContact employee, with fields for review period, rating score, goal text, and feedback. In-progress review cycles migrate as-is with a status flag; finalization must be completed in the destination system after cutover. Review cycle definitions and rating templates do not migrate as configuration data.

greytHR Users are HR admins, managers, and employees with role-based access. Bullhorn Users are recruiters, sales staff, and administrators with a UserType (Admin, Regular, Portal). We extract the greytHR user list, map HR admin roles to Bullhorn Admin users and manager roles to Bullhorn Regular users with appropriate object and field permissions. Role definitions (permission sets, approval authority, data access scope) are greytHR platform logic and do not export; we document the current role hierarchy for the customer's Bullhorn admin to rebuild using Bullhorn's role and permission tooling.

greytHR maintains a tamper-evident audit trail covering payroll, leave, and employee data changes. Bullhorn's own audit log tracks user actions within the ATS. We export the greytHR audit log records for the most recent 12 months as a supplementary compliance package delivered alongside the migration, stored as a CSV or JSON archive. This does not replace Bullhorn's native audit trail; it supplements it for the period prior to cutover. Audit log volume is typically manageable (a few hundred to a few thousand records per month depending on company activity).

greytHR custom fields on Employee records and its List of Values (LOV) picklist definitions map to Bullhorn custom fields and dropdown values. We export both the custom field values stored on each employee and the LOV definitions (display label, API value, sort order). Bullhorn custom fields are created via Admin > Field Mappings, and picklist values are entered in the field's value list. Bullhorn editions limit the number of custom fields per entity (Growth supports a defined set; Enterprise supports more). We prioritize migration of custom fields that contain statutory data, compensation data, or custom status fields, and document remaining custom fields for post-migration manual entry.