Migrate from Jobylon to Bullhorn ATS & CRM

Jobylon Job records map to Bullhorn JobOrder. Standard fields (title, department, location, description, employment type) migrate directly. Per-company custom fields defined in /config/companies/{companyId}/job map to Bullhorn custom fields on JobOrder. Bullhorn enforces field character limits (some capped at 100 characters, others unlimited) — we analyse source field lengths during discovery and flag any that require truncation or multi-field splitting. Job status (active, paused, closed) maps to Bullhorn JobOrder status with the original status preserved in a custom field for audit.

Jobylon Candidate records map to Bullhorn Candidate with deduplication by email address. A Candidate with multiple Applications across Jobs retains a single Bullhorn Candidate record with all Application histories linked. GDPR fields (consent granted date, erasure request date) migrate as custom fields on the Bullhorn Candidate because Bullhorn's standard Candidate does not include a native GDPR consent timeline. Phone, email, address, LinkedIn URL, and skills migrate to their Bullhorn equivalents. Resume files migrate as ContentDocument records attached to the Candidate.

Jobylon Application records (linking a Candidate to a Job with a Pipeline Stage assignment) map to Bullhorn JobSubmission. The source Application ID is preserved in a custom field on JobSubmission for traceability. Application date, rejection date, and withdrawal date migrate as submissionTimestamp and statusChangeDate. Lost Reasons (free-text classification labels assigned when an Application moves to an inactive stage) migrate as a tagged custom field on JobSubmission rather than a native Bullhorn object.

Jobylon pipeline stages are free-text and configurable per-company, with no standardisation across organisations. We map each distinct source stage name to a Bullhorn Sales Process stage value and create a corresponding Record Type on JobOrder. Inactive stages with assigned Lost Reasons are flagged as termination states and mapped to Bullhorn's Lost or Withdrawn stage values. The original stage name is preserved in a custom field for customer review before cutover. Bullhorn limits stage probability to integer percentages — we round source probability values to the nearest integer.

Jobylon Scorecards are tied to Pipeline Stages and record evaluations by specific Users with rating values and evaluator comments. We export the scorecard schema, rating values, and evaluator name. Bullhorn does not have a native scorecard object in standard editions, so we create a Bullhorn Custom Object (customObject1 through customObject10 depending on edition tier) with typed fields for rating category, score value, evaluator name, and timestamp. Bullhorn ATS Growth has no custom object support — in that case we map scorecards to Note records attached to the JobSubmission.

Jobylon Users (recruiters, hiring managers, admins with configurable permission levels) map to Bullhorn User records. We resolve by email match. Any Jobylon User without a matching Bullhorn User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Permission levels map from Jobylon role definitions to Bullhorn permission sets or profiles, with the customer admin making the final assignment during Bullhorn setup.

Jobylon custom fields for Jobs are defined per-company via the Partner API, not globally. We query /config/companies/{companyId}/job for each company during discovery to build a complete field map. Bullhorn custom fields on JobOrder are limited per entity — we use standard Bullhorn custom fields first and escalate to custom objects for overflow. Dynamic custom fields (which build secondary forms based on prior submissions) must be confirmed as activated by Jobylon support before schema discovery; if not confirmed, those fields are flagged as a data gap in the discovery report.

Jobylon Application custom fields follow the same per-company schema pattern as Job custom fields. We map them to Bullhorn JobSubmission custom fields where the Bullhorn edition supports them. Bullhorn ATS Growth limits custom fields per entity — we scope the mapping to the customer's edition during discovery and flag any fields that exceed the per-entity limit, recommending a custom object or a consolidation strategy.

Free-text evaluator notes and assessor feedback export as structured comment records from Jobylon. We preserve the author name, timestamp, and content body and map them to Bullhorn Note records attached to the JobSubmission, with the original author name and date in custom note fields. Bullhorn's native Notes object supports rich text, so formatted feedback content transfers without loss.

Jobylon stores offer letter documents as Application attachments with only filenames and URLs accessible via API — document content is not exported. We migrate the attachment URLs and filenames as Bullhorn ContentDocument records linked to the Placement or JobSubmission. The customer's admin should verify whether the original offer letter files are accessible from the Jobylon hosted environment before the account is closed. We document this gap in the handoff report and recommend a backup step during the pre-migration freeze window.

Jobylon does not have a native Client Corporation concept — its equivalent is the Employer entity or company record embedded in the Job configuration. Bullhorn uses Client Corporation as a separate entity linked to JobOrder and Candidate. If the migration scope includes moving employer-client data (for staffing agencies that also manage client relationships in Jobylon), we create Client Corporation records from the employer names associated with Job postings, with the original Jobylon employer identifier preserved as a custom field.

For staffing agencies that use Jobylon's employer-facing pipeline for client outreach (rather than candidate-facing applications), we treat inbound employer inquiries as Bullhorn Leads. The source employer name, contact email, and any associated job requirements map to Bullhorn Lead fields. Conversion rules are defined with the customer admin during scoping so that employer Leads convert to Client Corporation and Contact records post-migration.