Migrate from WebHR to Bullhorn ATS & CRM

WebHR Employee records map to Bullhorn Candidate records. We extract the full profile (name, contact, employment history, skills, resume) and map it to Bullhorn Candidate fields. WebHR's employee photo migrates as a Candidate attachment. The Candidate's status defaults to 'Active' if the WebHR employee is currently employed, or 'Placed' if a historical placement record exists. We preserve the original WebHR employee ID in a custom field webhr_employee_id__c for audit and reconciliation.

WebHR Employee records may also represent internal client contacts if the organization uses WebHR to track relationships with external clients. We map these to Bullhorn ClientContact records linked to the corresponding ClientCorporation, with the employee role mapped to the ClientContact title field.

WebHR's CompaniesList endpoint maps directly to Bullhorn ClientCorporation. The organization name, address, and industry classification migrate as ClientCorporation fields. For multi-entity WebHR deployments, we extract each company as a separate ClientCorporation and preserve the parent-child hierarchy via ClientCorporation custom fields.

WebHR Recruitment Candidates are created through the ATS module and include application stage, screening data, and attachments. We map these to Bullhorn Candidate records with the WebHR application stage preserved in a custom field webhr_stage__c. If the candidate is tied to an active job opening, we create a Bullhorn JobSubmission linking the Candidate to the corresponding JobOrder. WebHR pipeline stage names vary by customer configuration; we extract the actual stage names during discovery and map them to Bullhorn's standard submission status values.

WebHR's customer-defined pipeline stages (e.g., Screening, Technical Interview, Culture Fit) have no Bullhorn standard equivalent. We configure Bullhorn JobSubmission status values to match the customer's pipeline stages, creating custom status options where needed. For complex multi-stage pipelines with branching logic, we document the stage progression in a custom object or as a field mapping note for the admin to configure in Bullhorn's pipeline settings post-migration.

WebHR leave records (leave type, start/end dates, status, balance consumed) have no native Bullhorn equivalent because Bullhorn is a recruitment platform. We migrate leave history as Note records attached to the Candidate, or as a Bullhorn Custom Object (LeaveHistory__c) if the customer has Front Office Growth or Enterprise edition and wants structured leave data. Balance forward is calculated and noted. We flag any leave records that may contain sensitive HR data and recommend the customer's admin review before making them visible on candidate profiles.

WebHR Performance module stores review records linked to employees with ratings, goals, and feedback text. Custom review templates and rating scales differ across accounts. We map these to Bullhorn Custom Object records (Review__c) linked to the Candidate, or as structured Notes if the Bullhorn edition does not support Custom Objects. Rating scales are preserved as custom picklist fields; goals and feedback text migrate as long-text fields.

WebHR payroll records (payslips, year-to-date earnings, deductions) are available via API only if the payroll add-on ($2/employee/month) is active. We migrate payroll summary data as structured fields on the Bullhorn Placement record (if the customer uses Bullhorn Back Office for placement payroll) or as Notes attached to the Candidate. Bullhorn does not have a payroll module for general HR payroll; the Back Office handles contractor and placement billing, not employer payroll.

WebHR clock-in/clock-out timestamps and approved timesheet data migrate to Bullhorn Placement records (for placed candidates) or a Custom Object (Timesheet__c) for tracking. We extract approved timesheet records and flag any unprocessed or pending entries that require manual resolution. Timesheet data linked to billable placements maps to Bullhorn time and expense records.

WebHR's Files module stores employee documents (contracts, IDs, certifications) as binary blobs. We enumerate all file metadata, download the blobs, and re-upload them as Bullhorn Candidate attachments and ContentDocument records, preserving filenames and original upload dates. Document type is mapped to Bullhorn's attachment description field.

WebHR benefit enrollment records (benefit type, coverage level, enrollment dates) migrate to Bullhorn Custom Object (BenefitEnrollment__c) linked to the Candidate, or as structured Notes if Custom Objects are unavailable. Dependent and beneficiary details map as sub-records or custom fields within the BenefitEnrollment object.

WebHR eSignature records (signed documents, signatory, signing date, audit trail) are migrated as Notes attached to the Candidate with the original signatory, timestamp, and signature status preserved in the note body. Bullhorn's native e-signature capability via integrations (DocuSign, AdobeSign) can be re-connected post-migration; the migration preserves the historical record of signed agreements.

WebHR custom forms contain field data tied to specific employees. We export form response records and field values, mapping them to Bullhorn Custom Objects (one per form type) with custom fields matching the source form fields. Field types are mapped to equivalent Bullhorn custom field edit types (text, picklist, date, checkbox). If the destination Bullhorn edition supports fewer than the required custom objects, we prioritize the most operationally critical forms.

WebHR Scheduler module stores shift assignments, rosters, and shift swap records. We extract active shift patterns and map them to Bullhorn Event records (for scheduled activities) or a Custom Object (Shift__c) linked to the Candidate Placement. Recurring shift patterns are documented for the customer's admin to configure in Bullhorn's calendar or Bullhorn Onboarding (Able) if shift scheduling is a recurring operational need.

WebHR users who created or owned records map to Bullhorn User records. We resolve WebHR users by email match against the Bullhorn User table. Any WebHR user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Inactive WebHR users are mapped to inactive Bullhorn Users to preserve assignment history.