Migrate from Grove HR to Bullhorn ATS & CRM

Grove HR Employee records form the basis of the Bullhorn Candidate object. We map firstName, lastName, email, phone, jobTitle, startDate, employmentStatus, and department to Bullhorn Candidate's corresponding standard fields. The employee's employment status (active, on leave, terminated) maps to Bullhorn's status and dateLastNote fields. Any Grove HR custom fields on Employee (for example, employee ID, cost centre, shift pattern) map to Bullhorn custom fields on Candidate. This is the anchor record for the entire migration; all other HR objects resolve back to it via a CandidateID lookup.

Grove HR leave balances (annual entitlement, sick leave, parental leave, accrued balance, carried-over balance) and historical request records have no native Bullhorn equivalent. We create Bullhorn custom objects scoped to Candidate—one per leave type—and store entitlement, balance, and last-approved-request date as custom fields. Leave approval status and approver details are stored as additional fields. Bullhorn ATS is limited to 2 custom objects; Growth and Enterprise editions allow up to 10. If the customer has more leave types than the destination edition permits, we consolidate into a single LeaveBalances custom object with a leaveType picklist and per-type balance fields, or we flag overflow types for manual reconciliation.

Grove HR candidate records from the recruitment pipeline map to Bullhorn Candidate. The Grove HR pipeline stage (application received, screening, interview, offer, hired) maps to Bullhorn's candidateStatus and to a corresponding Job Order's hiring pipeline stage. When Grove HR records represent a successfully placed candidate, we create a Bullhorn Placement record linked to the Candidate and the Job Order. If the placement includes compensation details (salary, commission rate, start date), these map to Bullhorn Placement's payRate, billRate, and startDate fields.

Grove HR onboarding checklists are task templates assigned per employee. Offboarding has its own checklist variant. Bullhorn does not have a native onboarding checklist model; Job Orders support task assignments but not reusable template-based checklists. We decompose the assigned checklist tasks (task name, assignee, due date, completion status) and map them to a Bullhorn custom object OnboardingTasks scoped to the Candidate record, or we document them as a Bullhorn Onboarding (Able) setup plan for the customer's admin. The checklist template itself is not a transferable object; we deliver a written inventory of all active templates with their task structure for rebuild.

Grove HR performance review cycles contain structured rating fields, reviewer assignments, comments, and overall scores per employee. Bullhorn has no native performance review object. We create Bullhorn custom objects scoped to Candidate—one per review cycle—and store review period, reviewer name, rating fields, overall score, and comments as custom fields. In-progress or draft reviews are flagged in a separate reconciliation note since only completed reviews are migrated. If the customer has more than two review cycles per year and the Bullhorn edition limit is reached, we consolidate by year or flag overflow for post-migration manual entry.

Grove HR goals are linked to employees with progress tracking, due dates, and linked key results. Bullhorn has no native goal-tracking module. We create a Bullhorn custom object Goals scoped to Candidate and store goal title, description, progress percentage, due date, and key results as custom fields. Orphaned goals (no active employee owner) are flagged for manual review and either assigned to a designated admin or excluded from migration with a count delivered in the reconciliation report.

Grove HR training modules and employee completion records (module name, completion date, score, status) are stored per employee. We map these to a Bullhorn custom object Training scoped to Candidate. Training course content (video files, slides, SCORM packages) does not migrate; only the enrollment record (who completed what, when, with what result) transfers. If the customer uses a separate learning management system, we flag the training records as suitable for a cross-system reference rather than Bullhorn storage.

Grove HR stores company-level settings, departments, and locations. Bullhorn uses ClientCorporation to represent client companies in the recruiting relationship. We map Grove HR departments and locations to Bullhorn ClientCorporation fields (name, address, city, country) and create separate ClientCorporation records for each distinct Grove HR location if the customer's Bullhorn workflow tracks client offices. If Grove HR stores the customer's own organisation as a company record, that maps to a ClientCorporation with a flag indicating it is the customer's own entity rather than a recruitment client.

Grove HR clock-in/out events, timesheets, and overtime flags are used for payroll calculation in some Grove HR configurations. Bullhorn is not a time-and-attendance system; it records placement hours worked for billing purposes on Placement records. We export timesheet summary data (total hours per period, overtime flags) and map it to a Bullhorn custom object Timesheets scoped to Candidate, or we attach it as a Note to the Candidate record. Raw clock-in/out events are typically out of scope unless the customer has a specific billing need tied to placement hours.

Employee documents (contracts, offer letters, payslips) export from Grove HR as binary files linked to each employee record. We import these as Bullhorn ContentDocument records attached via ContentDocumentLink to the corresponding Candidate record. Document content is not parsed or transformed. Customers should confirm Bullhorn's storage limits and document retention policies before committing to a full document migration, as Bullhorn charges for storage above the org allowance. We deliver an inventory of document types and sizes before the migration to allow informed scoping decisions.

Grove HR custom fields are defined on Employee and other objects. We detect all custom field definitions during scoping, map each to a Bullhorn custom field on the equivalent object (Candidate, ClientCorporation, Job, Placement), and pre-create the Bullhorn field schema before any data import. Bullhorn enforces field-type constraints (text, number, picklist, date, checkbox, etc.) and per-field edit-type limits. We validate the Grove HR field type against Bullhorn's available custom field types and flag any that require a Bullhorn custom object instead of a simple custom field. Custom field mapping is delivered in a written data dictionary before extraction begins.

Grove HR owners (HR admins, line managers assigned to onboarding checklists, leave approvers) are referenced on employee records and checklist tasks. We resolve Grove HR owners by email against Bullhorn User records in the destination org. Any owner without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record migration proceeds. Inactive Grove HR users are mapped to inactive Bullhorn Users to preserve historical assignment without giving former employees system access.