Migrate from RESUMate to Bullhorn ATS & CRM

RESUMate Candidate records map directly to Bullhorn Candidate. Parsed resume text, contact details (name, email, phone, address), and source attribution migrate as standard Candidate fields. Unlimited RESUMate notes map to Bullhorn Note records linked via ContentDocumentLink. For candidates with extensive free-text notes accumulated over years of use, we preserve all notes as Note body content ordered by RESUMate's timestamp. Candidate custom fields from RESUMate map to Bullhorn Custom Objects attached to the Candidate entity; Bullhorn Support must provision these Custom Objects before migration ingestion begins.

RESUMate Client records (employer or company records) map to Bullhorn ClientCorporation. The company name, industry classification, address, and contact details migrate as ClientCorporation fields. We use ClientCorporation name as the dedupe key during ingestion. If the customer has multiple Client contacts per company in RESUMate (e.g., hiring managers, procurement contacts), we map these to separate ClientContact records linked to the ClientCorporation.

RESUMate Job Order records (job requisitions linked to Clients) map to Bullhorn JobOrder. Job title, job description, requirements, status, and internal job ID migrate as standard fields. The Client-to-Job-Order relationship from RESUMate resolves to the Bullhorn ClientCorporation reference on JobOrder. Job Order status (Active, Filled, On Hold, Cancelled) maps to Bullhorn JobOrder status field equivalents.

RESUMate Active Jobs are filtered views of Job Orders organized by pipeline stage and status. These are derived views, not separate records. We extract Active Jobs data to capture pipeline stage assignments (e.g., Searching, Interviewing, Offered, Placed) and apply them as Bullhorn JobOrder status values or custom status fields on JobOrder. Bullhorn does not have a native Active Jobs pipeline view equivalent; pipeline visualization is handled through Bullhorn's list views and reporting rather than a separate object.

RESUMate Send-outs track when a Candidate is submitted to a Job Order. This is a core Part IV workflow in the RESUMate Getting Started Guide. We map Send-outs to Bullhorn JobSubmission records, which represent a Candidate's submission to a specific JobOrder. The submission date, send-out status (Active, Interviewing, Rejected, Placed), and any associated notes migrate as JobSubmission fields. We preserve the three-way Candidate-to-Job-Order link explicitly through the JobSubmission entity rather than the implicit relational model RESUMate uses.

RESUMate Groups are named lists organizing Candidates, Clients, or Job Orders. We export Group membership as a tag or segment membership dataset. In Bullhorn, Candidate tags migrate as text values in a custom tag field or as Bullhorn List membership (Candidates can belong to multiple Lists). The customer chooses between tag-field and List-based segmentation during scoping based on their ongoing segmentation workflow in Bullhorn.

RESUMate Calendar events are scheduling records linked to Candidates, Clients, or Job Orders. We extract event details including date, type (interview, client call, internal meeting), and notes, then map them to Bullhorn Event records with EventRelation links to the relevant Candidate, ClientContact, or JobOrder. Bullhorn Event's StartDateTime and EndDateTime preserve the original scheduling timestamp; attendee information migrates as EventRelation records.

RESUMate supports unlimited custom fields per installation, and users report barely scratching the surface of available custom fields over years of use. Bullhorn supports up to 10 Custom Objects per entity (Candidate, ClientCorporation, JobOrder, etc.) with 55 fields each on Growth/Enterprise editions, and 2 Custom Objects on Bullhorn ATS. During discovery we capture the full RESUMate custom field schema and rank them by usage frequency. Bullhorn Support must provision each Custom Object via a spreadsheet submission ticket before migration. We do not migrate custom field logic or validation rules; these are rebuilt in Bullhorn Field Mappings post-migration.

RESUMate stores both parsed resume text (in the Candidate record) and original file attachments in proprietary format. We extract original resume files (Word, PDF, plain text) as binary files and attach them to Bullhorn Candidate records as ContentDocument via the Bullhorn REST API's file attachment endpoint. Bullhorn's resume parsing capability (via DaXtra) can re-parse the attached file into structured Candidate fields if the original parsed text is incomplete. We ingest resume attachments after Candidate records are created so that the ContentDocumentLink relationship is satisfied at insert time.

RESUMate Candidate records hold unlimited free-text notes with timestamps. We export notes as a dedicated dataset and import them as Bullhorn Note records linked via ContentDocumentLink to the parent Candidate, ClientCorporation, ClientContact, or JobOrder. Note body migrates as rich text. Bullhorn Note supports up to 131,072 characters, which covers the vast majority of RESUMate notes; notes exceeding this limit are flagged for manual review before migration.

RESUMate tracks which user created or owned a record (Candidate, Client, Job Order, Send-out). We extract distinct owner references and match them by email against Bullhorn User accounts. Owners without a matching Bullhorn User go to a reconciliation queue; the customer's Bullhorn admin provisions missing Users before record import resumes. Migration cannot proceed past user resolution because OwnerId references are required on standard Bullhorn objects.

For customers running RESUMate Desktop, the database resides on local Windows PCs. Data extraction requires a local export from the Desktop application. If the Desktop installation has been dormant or the customer lacks local admin access, we coordinate a remote or on-site extraction session. Desktop exports are often larger and less consistently formatted than Cloud exports because Desktop installations may have custom modifications. We perform a data profiling pass on Desktop exports to identify encoding inconsistencies, missing fields, and record-level anomalies before designing the transformation script for Bullhorn API ingestion.