Migrate from Mitratech Circa to Bullhorn ATS & CRM

Circa Jobs (the primary container for requisition details, location data, EEO-1 category classifications, and posting status) map directly to Bullhorn JobOrder. The Circa job ID is preserved in a custom Bullhorn field circa_job_id__c for audit traceability. We map Circa's posted-date and ESDS posting status to Bullhorn JobOrder custom fields, noting that Bullhorn does not have native ESDS scraping; the customer's admin recreates posting schedules using Bullhorn's job distribution settings or a third-party integration.

Circa Applicant records (name, contact, application stage, source attribution, and diversity sourcing tags) map to Bullhorn Candidate. The diversity sourcing tag structure in Circa—badges and source categories used for AAP reporting—migrates to Bullhorn Candidate custom fields (text, picklist, or multi-select depending on tag cardinality). We preserve the original application date and stage at time of migration in custom fields circa_application_date__c and circa_stage__c.

Circa Outreach Records are separate entities linked to Jobs by ID, holding partner name, contact, outreach date, and response status. Bullhorn has no native Outreach Record entity, so we split the data: the outreach interaction (date, type, status, notes) becomes a Bullhorn Task linked to the related JobOrder and ClientContact; the partner contact record (if not already in the Community Partner Directory) becomes a ClientContact with a custom field indicating the outreach_program flag. Response status from Circa maps to a custom Task field outreach_response_status__c.

Circa Community Partner Directory entries (structured contacts outside the organization who receive job postings and diversity outreach communications) map to Bullhorn ClientCorporation as the organization record and ClientContact as the individual. The diversity focus tags associated with each partner (Circa's structured tag system for DEIB tracking) migrate to Bullhorn ClientContact custom fields. We deduplicate against existing Bullhorn ClientCorporation and ClientContact records using organization name and email match before inserting.

Circa AAP data—derived from applicant flow logs and workforce composition snapshots including job group analysis, placement goals, and contractor veteran/disability metrics—has no standard Bullhorn equivalent. We design a Bullhorn Custom Object schema (CustomObject1 through CustomObject3 depending on edition) with fields for job_group, placement_goal, goal_percentage, actual_percentage, veteran_count, and disability_count. Each AAP record links to the relevant JobOrder via a lookup field. The customer provisions the Custom Object through Bullhorn Support before migration using the Custom Object Setup Sheet.

Circa resume records (parsed candidate profiles and source attribution from the searchable resume repository) map to Bullhorn Candidate with the resume file attached via ContentDocumentLink. Resume metadata (parsed fields, source board, intake date) migrates to Bullhorn Candidate custom fields. We parse Circa resume export files (CSV with base64-encoded attachment or file reference) and attach the parsed document to the matching Candidate record using Bullhorn's resume parsing API if Bullhorn's resume parsing integration is active.

Circa Employer Profile settings (company description, diversity commitments, featured tags, and branding used on job postings) map to Bullhorn ClientCorporation profile fields and custom text fields. Diversity commitment text migrates to a Bullhorn ClientCorporation custom field diversity_statement__c. We extract profile tag configurations and recreate them as Bullhorn ClientCorporation custom picklist values during the migration.

Circa tracks ESDS job board subscription configurations and posting history internally as part of the Jobs module. Bullhorn has no native ESDS posting tracking. We capture the job board subscription list and posting history in a CSV during extraction and deliver it as a Bullhorn JobOrder custom field set (board_name__c, last_posted_date__c, posting_status__c) for the customer's admin to recreate posting schedules in Bullhorn's job distribution settings or a third-party job aggregation tool.

Circa supports custom fields on Jobs depending on the active feature tier. We audit the full custom field schema from an account with full feature access before building the extraction map and verify field counts against record counts to catch silent drops (a known Circa gotcha where fields from premium tiers do not appear in exports from lower-privilege accounts). Bullhorn JobOrder custom fields are created via the Bullhorn Field Maps interface or REST API before migration; we map each Circa custom field to the equivalent Bullhorn field type.

Circa Applicant custom fields (including diversity sourcing fields, EEO-1 classification fields, and any employer-defined intake fields) map to Bullhorn Candidate custom fields. We create Bullhorn custom fields via Field Maps with matching edit types (text, picklist, date, number). The 55-field limit per Bullhorn Custom Object applies only to Custom Objects, not to standard entity custom fields; Candidate supports extensive custom fields within standard Bullhorn field limits.

Circa Community Partner custom fields (focus area tags, partnership tier, outreach history counters) map to Bullhorn ClientContact custom fields. We verify that the destination Bullhorn edition includes sufficient custom field capacity for the partner record schema before migration. Bullhorn ATS edition has a lower custom field limit than Growth or Enterprise; we confirm the edition during scoping and flag any capacity constraints before extraction begins.

Circa user accounts (name, role, and feature-module access level) map to Bullhorn User records. We extract the user roster and role assignments from Circa and map them to Bullhorn roles and department assignments. Circa's feature-tier access flags do not have a direct Bullhorn equivalent; we document the original access configuration in a Bullhorn custom field or in the handoff document so the customer's Bullhorn admin can configure matching permissions post-migration. Active Circa users are provisioned as active Bullhorn users; inactive users are provisioned as inactive for record ownership continuity.