Migrate from CatalystOne to Bullhorn ATS & CRM

CatalystOne Person records map to Bullhorn Candidate records. Core fields (firstName, lastName, email, phone, employmentStatus, startDate, endDate, department, manager reference) migrate directly. The manager relationship resolves to a Bullhorn User lookup after User provisioning. Employment status maps to Candidate status (active to active/open, terminated to placed/archived). Work email and personal contact fields merge into Bullhorn's Candidate contact fields. Custom properties on the Person object (industry-specific or company-specific fields discovered during schema pass) map to Candidate custom fields or Candidate Custom Objects depending on field count. We preserve the original CatalystOne personId as a custom field cata_person_id__c for reconciliation.

CatalystOne's position-based data model maps to Bullhorn JobOrder. Position title becomes JobOrder title, department maps to JobOrder department, and position-specific competency requirements migrate to JobOrder requirements or to a Candidate Custom Object linking competency to the job. The position hierarchy (reportsTo, positionType) maps to JobOrder field values and a parent-child JobOrder relationship where applicable. Effective dates on position records (hiring date, end date, effectiveFrom, effectiveTo) are flattened into a single JobOrder with startDate and expectedEndDate since Bullhorn does not natively support effective-dated position history.

CatalystOne competency records (many-to-many person-to-competency with rating, expiry, and acquisition date) require a Custom Object in Bullhorn since Bullhorn has no native competency or skills-object. We design a competency custom object with fields for competencyName, rating, expiryDate, and acquisitionDate, linked to the Candidate record. Edition constraint: ATS Growth has zero Custom Object capacity, Bullhorn ATS supports 2, and Front Office Growth and Enterprise support 10. We confirm the customer's Bullhorn edition during scoping and cap the competency custom object design accordingly. For up to 5 key competencies, we use Candidate custom fields directly; for fuller competency profiles we reserve a dedicated custom object.

CatalystOne succession plans store a structured relationship between a Position and one or more candidate Persons with readiness ratings. Bullhorn has no native succession planning object, so we create a SuccessionPlan custom object linked to the JobOrder (representing the position) and to Candidate records (representing the succession candidates). Readiness rating, readinessDate, and notes migrate as custom object fields. This requires the customer's Bullhorn edition to support at least one custom object. We flag this during scoping if the customer is on ATS Growth (zero custom objects) so the succession plan mapping strategy is defined before migration begins.

CatalystOne performance review records carry effective dates, reviewer assignments, ratings, and comments against a Person or Position. We map these to a PerformanceReview custom object linked to the Candidate record, with fields for reviewDate, reviewerUser (lookup to Bullhorn User), overallRating, and structured comment sections. Custom review templates mean the field set varies per customer, which is why a pre-migration schema discovery pass against the customer's specific CatalystOne tenant is required. We enumerate all active review fields and map them to Bullhorn custom object fields during the schema design phase, not at migration time.

CatalystOne department hierarchy (departments with parent-child relationships and cost-centre assignments) maps to Bullhorn ClientCorporation records in a matching parent-child hierarchy. We create one ClientCorporation per department or cost centre, preserving the parentId reference. Effective-date changes to org structure in CatalystOne (structural changes over time) are not natively supported in Bullhorn; we capture the current active structure and document the historical changes separately for the customer's HR team to store as reference. Cost-centre codes migrate as ClientCorporation fields for finance reconciliation.

CatalystOne employee documents (employment contracts, certifications, policies) are binary files with type and date metadata. We export each document with its type classification, upload date, and owner reference, then attach them to the corresponding Candidate record in Bullhorn using Bullhorn's file attachment API. Document type maps to a Bullhorn Candidate field (e.g., certificationType or documentCategory) for filtering. Contract documents may alternatively route through Bullhorn's E-Signature integrations (DocuSign or AdobeSign via Bullhorn Marketplace) post-migration if the customer adopts electronic signing.

CatalystOne AD and SSO provisioning data linked from the HR master record is exported as a reference dataset (employee name, role, department, manager, AD group membership snapshot) rather than migrated into Bullhorn, because Bullhorn's User object represents system access users, not HR employee identity records. We deliver this as a structured CSV for the customer's IT team to use during Bullhorn User provisioning and Active Directory or SSO integration setup. The mapping does not create Bullhorn User records directly because User provisioning is an administrative act that requires the customer's Bullhorn admin to assign roles and validate access.

CatalystOne's managed Azure-hosted payroll integrations (field-to-field mappings to Visma, SAP, and regional Nordic payroll providers) are CatalystOne's intellectual property and are not exposed via API. The integration configuration is not handed over on exit. We export the current payroll data snapshot (employee payroll identifiers, compensation fields, pay grades) as a structured reference export for the customer's IT or payroll team to use when reconfiguring integrations in their chosen payroll destination (Bullhorn Middle Office or an independent payroll system). Bullhorn Middle Office handles time, expense, and back-office payroll for staffing firms but is not a direct CatalystOne payroll equivalent for Nordic employers.

CatalystOne approval workflows, automated triggers, and HR process rules are configured within the application and are not exposed via API. We do not migrate workflow logic. We document all active workflow configurations during the discovery phase (approvals, triggers, escalation rules, task automation) as a written inventory with screenshots and rule descriptions so the customer's HR admin can plan the rebuild in Bullhorn's workflow builder or engage a Bullhorn implementation partner for automation reconfiguration.

CatalystOne's time-tracking module (if used) exports timesheet records and accrual balances, but Bullhorn's ATS and CRM does not natively store time and attendance data. Bullhorn Time & Expense (part of Bullhorn Middle Office) handles time capture for placed contractors and back-office payroll for staffing firms but is a separate product and licensing tier. We scope time and attendance records out of the standard migration unless Bullhorn Middle Office is included in the destination scope. Employee records and org structure migrate regardless of whether time data exists in CatalystOne.

CatalystOne stores compensation records as effective-dated entries (salary, bonus, equity, allowances) against a Person record. Bullhorn has no native compensation object. For active employees being placed, we map the most recent compensation snapshot to Candidate custom fields (currentSalary, currentBonus). For organisations requiring full compensation history (for audit, reporting, or payroll reconciliation), we design a CompensationHistory custom object with effectiveDate, salaryAmount, currency, bonusAmount, and equityDetails fields linked to the Candidate. This requires at least one Custom Object slot on the destination Bullhorn edition.