Migrate from Martian Logic to Bullhorn ATS & CRM

Martian Logic Employees with an active employment status and a history of recruitment activity map to Bullhorn Candidate records. Employees with no recruitment activity but an ongoing employment relationship map to Bullhorn ClientContact records if they represent client organisations, or remain as Candidate records with a custom employment_status__c field. We split on the Martian Logic employment status property and the presence of ATS conversion events. The original Employee record ID is preserved as ml_employee_id__c on the Bullhorn record for audit reconciliation.

Martian Logic's ATS Candidates — records in the recruitment pipeline before or after conversion — map directly to Bullhorn Candidate. We extract candidate status history, application dates, interview scores, and source attribution from the Martian Logic ATS module and map these to Bullhorn's Candidate status, dateAdded, candidateSource, and custom rating fields. If the candidate was converted in Martian Logic, the conversion event is preserved as a note and the converted flag is set on the Bullhorn Candidate.

Martian Logic Positions are first-class objects linked to employees, driving the org chart and compensation. Bullhorn has no native position entity. We create a Position__c custom object (via Bullhorn Support ticket before migration) and map Position ID, title, department, level, FTE status, and the direct supervisor position ID. The position-to-position reporting chain is walked during extraction to reconstruct the full hierarchy, then written as parent_Position__c lookup references in Bullhorn. Bullhorn Enterprise and Front Office Growth editions allow up to 10 custom objects; Position__c consumes one slot.

The Martian Logic org chart is a derived view of Position relationships, not a standalone object. We walk the Position-to-Position reporting chain during extraction, resolve any archived or soft-deleted positions (orphaned nodes), and build the hierarchy as parent_Position__c lookups in the Position__c custom object. If positions have been improperly terminated in Martian Logic, orphaned nodes are flagged in the discovery report for the customer to resolve before migration.

Martian Logic Compensation is stored within or linked to Positions via the Role and Remuneration Library — base salary, allowances, pay frequency, and effective dates. Bullhorn has no native compensation object. We create a Compensation__c custom object with fields for base_salary__c, pay_frequency__c, effective_date__c, allowance_type__c, and allowance_amount__c, linked to the Position__c custom object. If multiple compensation records exist per position (historical changes), all effective-dated records are migrated with a compensation_effective_from__c field.

E-forms completed during onboarding are stored as JSON payloads per employee. Field names, types, and mandatory/optional status differ per employer pack configuration — there is no fixed schema. We parse each payload individually during extraction and map each field to Bullhorn custom object fields. Multiple pack configurations result in multiple custom objects, each mapped to the Candidate record via lookup. Field types (date, text, checkbox, dropdown) are matched to Bullhorn edit types during schema creation. This mapping consumes custom object slots; Bullhorn ATS Growth is capped at 2 custom objects, making migrations with three or more e-form packs only viable on Bullhorn ATS, Core, or Enterprise tiers.

Change of Staff Conditions records are effective-dated transactions with change type, old value, new value, and reason. Martian Logic stores these as a transaction log per employee. Bullhorn has no native employment history object. We create an EmploymentChange__c custom object with fields for change_type__c, old_value__c, new_value__c, effective_date__c, reason__c, and a Candidate lookup. All change records are migrated as a flat per-employee change log. The customer should decide whether to display this as a dedicated tab in Bullhorn or keep it as an internal reference.

Martian Logic Requisition Workflow records (hiring requests before candidate assignment) map to Bullhorn JobOrder. We extract requisition title, requesting manager, approved headcount, status, and date created. Open requisitions become Bullhorn JobOrder records with status = Open; closed requisitions are migrated as historical records with status = Closed. The job title maps to title, and the requesting manager maps to the Bullhorn User lookup by email match.

Martian Logic Performance Review templates and completed reviews are stored against employees. Bullhorn has no native performance management object. We create a PerformanceReview__c custom object with fields for review_cycle__c, template_name__c, rating__c, goals__c, reviewer__c, and Candidate lookup. Mapping to Bullhorn is constrained by the destination's review template model; we document the review cycle structure and note that rebuilding review templates in Bullhorn requires the customer's admin to configure a new workflow or use a third-party performance module.

Integration Connectors in Martian Logic push employee data to third-party payroll systems and store field-to-field mapping configurations. These connector mappings are Martian Logic configuration artefacts and do not export from the platform. We document every active connector's mapping during discovery — source field, destination system, destination field — and deliver this as a written connector inventory for the customer's admin to manually re-establish in their target payroll system. We do not migrate payroll integration field mappings as data.

Martian Logic Compliance modules track regulatory requirements and attestations per employee — certification status, expiry dates, and attestation records. We create a Compliance__c custom object with fields for compliance_type__c, status__c, expiry_date__c, last_attested_date__c, and Candidate lookup. Bullhorn has no native compliance enforcement mechanism; migrated compliance status and expiry dates are stored as reference data, and the customer should configure renewal alerts in Bullhorn workflows or a separate compliance tool post-migration.

ESS access levels and role permissions are stored per employee or per role in Martian Logic. Bullhorn uses a role-based permissions model tied to Bullhorn User records, which is separate from Candidate records. We export ESS access levels and role assignments as custom fields on the Candidate record (ess_access_level__c, bullhorn_role_mapping__c) for reference. Bullhorn's access control logic is rebuilt by the customer's admin as part of the Bullhorn setup — we do not migrate ESS roles as Bullhorn roles because the permission models are not equivalent.

Martian Logic Candidates that exist in the ATS pipeline before conversion but represent prospects rather than placed or employed individuals map to Bullhorn Lead records if the customer uses Bullhorn's Lead object for early-stage pipeline tracking. The mapping uses the Martian Logic candidate status at extraction time: pre-conversion statuses map to Lead, post-conversion statuses map to Candidate. Lead scores and source attribution from Martian Logic migrate to Bullhorn Lead custom fields.